Gitkraken coincé à l'ouverture du dépôt
Chaque fois que j'ouvre gitkrarken, il reste bloqué à l'ouverture de l'icône de dépôt. Je ne peux pas ouvrir/cloner/init repo. J'ai entendu dire que d'autres avaient le même problème, mais personne ne semble savoir pourquoi cela se produit et quelle est la solution. Quelqu'un peut-il aider avec ça?
PDATE 1 Réinstallez-le. Toujours avoir le même problème
Fermez gitkraken et allez dans votre répertoire personnel. Supprimez le dossier caché ".gitkraken". Le dossier ".gitkraken" sera créé automatiquement au redémarrage. Cette solution fonctionne pour moi.
Pour les utilisateurs mac et linux: rm ~/.gitkraken
Pas une solution appropriée, mais j'ai le même problème. J'ai pu contourner ce problème en fermant Visual Studio avant d'ouvrir GitKraken. Il reste bloqué lors de l'ouverture et VS est déjà ouvert.
Actuellement, je cherche -> Recharger (Ctrl + R).
Je viens d'avoir un problème similaire (peut-être le même) avec GitKraken V2.7.0 x64 sous Windows. GitKraken s'est écrasé et a essayé d'ouvrir le dépôt après cela. Cela n'a jamais fini. Je suppose que cela est dû à Visual Studio qui était ouvert à l'époque et VS et GitKraken ne sont pas exactement des amis. J'ai tué GitKraken, fermé VS. Après cela, lors de l’ouverture du dépôt dans GitKraken, le message "Il n’ya pas de dépôt, voulez-vous l’initialiser?". Cela a également échoué. Je ne sais pas quelle est la cause du problème.
La solution consistait cependant à extraire une autre branche de la CLI. Après cela, GitKraken fonctionna à nouveau comme par magie. Peut-être que cela aide quelqu'un.
J'ai supprimé manuellement tous les fichiers avaient [conflict] dans leurs noms de .git dossier et ses sous-dossiers. Ensuite, j'ai effectué un git gc pour compresser la base de données et enfin git fsck pour m'assurer que tout va bien. Maintenant, je peux ouvrir le dépôt dans GitKraken .
Notes:
- This pourrait être utile pour supprimer tous les fichiers marqués comme
'[conflict]'. - La combinaison a fonctionné pour moi, mais vous n’aurez peut-être pas besoin de suivre toutes ces étapes. Par exemple, il se peut que vous n'ayez pas de fichiers en conflit ou que vous souhaitiez simplement les résoudre différemment plutôt que de les supprimer.
Supprimer le fichier index.lock de mon dossier Projet/.git a fonctionné pour moi. Btw c'est un dossier caché.
Pour nous, c’est le fait que l’un de nos gars a cloné le référentiel dans un dossier OneDrive.
Lorsque le référentiel se trouvait dans un dossier OneDrive, GitKraken s'ouvrait puis s'actualisait constamment pour que vous ne puissiez rien cliquer ou rien faire. Vous pouvez décrire cela comme si GitKracken avait l'air de "clignoter" à l'écran.
Dès que nous avons déplacé le référentiel dans un dossier non surveillé par OneDrive, tout a bien fonctionné.
À présent, je suis sûr que cette réponse n’aidera pas qui a posé la question, mais peut-être que cela aidera les gens à l’avenir. Je viens tout simplement de supprimer et de re-cloner le référentiel que GitKraken essayait d'ouvrir. A fonctionné à merveille pour moi.
Dans mon cas, le problème concernait un fichier .jfm (binaire) généré par mon projet SSDT (Sql Server Data Tools). Lorsque ce fichier change, GK commence à avoir ce problème. Si je valide (ou rétablis) manuellement ce fichier, le problème disparaît.
Pour moi, le problème était que la base de données git n'était pas compactée. git gui a montré cette notification ( entrez ici la description du lien ). En le compactant (via git gui ou git gc, je suppose), le problème avec GitKraken a été résolu.
Pour moi, suspendre GitKraken, si je supprime des branches localement ou à l’origine. Après cela, commencez à vous accrocher dans la fenêtre principale ou modifiez lister à droite. La petite aide est si vous exécutez "GIT GC" ( https://git-scm.com/docs/git-gc )
Dans notre cas, il y avait un document Latex dans le référentiel. Gitkraken n'a pas pu ouvrir le référentiel.
Selon les suggestions de @GeekyMonkey, mon élève a essayé de démarrer GitKraken après avoir fermé tous les fichiers et fermé son éditeur Tex.
Ça a marché après ça
vient d'avoir un problème similaire avec un projet spring-boot (mvc) avec base de données H2 intégrée, sur GitKraken (2.7.1)
Il s'avère que lorsque l'application est en cours d'exécution, cela causera ce problème sur du matériel sélectif utilisant ce référentiel. Assurez-vous donc que votre référentiel n'est pas utilisé de manière active lors de la synchronisation.
Je viens d'avoir le même problème. J'ai trouvé que mon .git/logs/HEAD avait une mauvaise entrée (je ne sais pas comment cela s’est passé ni pourquoi gitg et la CLI git ont toutes les deux ignoré le problème). Totalement un problème avec mon repo, pas GitKraken.
Plus de détails...
Pour comprendre cela, j'ai cloné le référentiel dans un répertoire séparé et meld 'leur a demandé de voir ce qui était différent. J'ai ouvert GitKraken à ce nouveau clone; Tout va bien. J'ai ensuite commencé à copier des éléments de l'ancien répertoire de dépôt vers le nouveau (objets, références, journaux, etc.). Une fois le fichier journal copié, GitKraken est revenu au message "Opening repo".
En fouillant plus profondément dans ce fichier journal, j'ai trouvé une mauvaise ligne. J'ai été en mesure de déterminer à partir du contexte comment recréer cette mauvaise ligne. Une fois que j'ai résolu le problème, GitKraken était heureux.
Mine fixe par
- Quittez GitKraken
- Ouvrez le terminal/invite de commande et faites un
git statussur le repo Constaté qu'il y avait quelques fichiers/dossiers non engagés/non mis en scène:
- Un lien symbolique pointant vers un dossier situé en dehors de mon référentiel a été renommé.
- Une copie de mon repo dans le même repo
- Un nouveau dossier avec des images
Renommé n ° 1 à son nom d'origine et supprimé manuellement les n ° 2 et n ° 3
- Ouvert gitkraken et il était capable de charger mon repo sans aucun problème
Dans mon cas, j'ai découvert que le problème était dû au fichier d'index situé dans le dossier ".git".
L'index est un fichier binaire (généralement conservé dans .git/index) contenant une liste triée de noms de chemins d'accès, chacun avec des autorisations et le SHA1 d'un objet blob.
git ls-filespeut vous montrer le contenu de l'index.
(Entrez le lien pour en savoir plus)
J'ai accidentellement supprimé certains fichiers de mon référentiel, ce qui explique la modification du fichier d'index. Par conséquent, mon Gitkraken coincé dans la boucle de l'infini.
Je viens de copier le fichier d'index dans le référentiel mis à jour précédent et de le coller dans le référentiel actuel. Ça marche pour moi.
J'avais le même problème et je ne pouvais pas le réparer avant d'avoir supprimé le dépôt qui, je le savais, était à l'origine du problème, puis de l'avoir créé à nouveau.
Fonctionne bien maintenant
J'ai eu ce problème en utilisant un repo, mais pas sur les autres. L'enfant à problème était assez grand et compliqué. J'ai essayé plusieurs des solutions ici en vain. Ensuite, j'ai essayé un patch assez évident - et mis à jour le logiciel. Je suis passé de GitKraken v3.x à v4.x et cela l’a fait!
Dans mon cas, ce problème de GitKraken se reproduit de façon stable lorsque je tente d’attacher du Dokku (https://github.com/dokku/dokku) référentiel distant avec git remote add. Le supprimer résout le problème. Je pense que Heroku repos peut causer le même problème, mais ne l'a jamais vérifié.
UPD: Ce n'est pas Dokku/Heroku qui cause des problèmes dans mon cas. À tout moment, lorsque j'utilise une URL de type SSH pour un référentiel distant (tel que [email protected]:reponame...), Je reçois un rechargement cyclique de GitKraken. Par coïncidence, Dokku et Heroku utilisent par défaut des URL de type SSH. Une fois que les URL de type SSH sont supprimées ou modifiées en HTTPS, GitKraken est ok.
J'ai eu le même problème. En lisant tout ce qui précède, il est apparu que mon flux de travail était incorrect. J'ai ouvert Excel et Notepad ++, etc. pour modifier le référentiel, puis j'ai ouvert GitKarken et j'ai été confronté au cercle de rotation. Bien sûr, tous ces autres programmes ont verrouillé les fichiers. Dès que j'ai fermé tous les autres programmes et que GitKraken a redémarré, cela a fonctionné! Un workflow plus correct serait donc d’ouvrir GitKraken en premier et de le laisser tout connecter, puis de travailler. S'engager n'était pas un problème après cela.