Dépôt Git cassé après la mort de l'ordinateur

Mon ordinateur est mort et maintenant l'un de mes dépôts git est cassé. Lorsque j'essaie de passer commande, il me dit:

warning: ignoring broken ref refs/heads/master.
error: Your local changes to the following files would be overwritten by checkout:
        com.vainolo.jdraw2d.releng.p2/pom.xml
Please, commit your changes or stash them before you can switch branches.
Aborting

Quand j'exécute git stash j'obtiens:

fatal: bad revision 'HEAD'
fatal: bad revision 'HEAD'
fatal: Needed a single revision
You do not have the initial commit yet

Alors qu'est-ce que je peux faire?

Mettre à jour la sortie de git reflog:

fatal: bad default revision 'HEAD'

Pas très prometteur ... Sortie de git fsck:

error: Invalid HEAD
Checking object directories: 100% (256/256), done.
error: unable to unpack 59551f96b4e87a1c14293c19eb548ce6fa1f196f header
error: inflateEnd: stream consistency error (no message)
fatal: loose object 59551f96b4e87a1c14293c19eb548ce6fa1f196f (stored in .git/objects/59/551f96b4e87a1c14293c19eb548ce6fa1f196f) is corrupt

J'ai réussi à récupérer grâce à:

rm .git/refs/remotes/origin/HEAD
git fetch --all

Commencez par suivre les étapes suggérées dans Récupération d'un référentiel git cassé :

• vérifier si .git/refs contient encore quelque chose d'utile
• vérifier git refloget à défaut que le contenu de.git/logs/refs/heads/master ou la branche sur laquelle vous étiez en dernier
• courir git fsck, potentiellement avec --unreachableou--lost-found

Nous espérons que cela vous permettra de déterminer ce que la masterréférence devrait être afin que vous puissiez la restaurer (c.-à-d. Insérer le SHA1 correct dans.git/refs/heads/master ).

Dans le cas où un objet contenu dans ce commit est véritablement corrompu, vous ne pouvez HEADmalheureusement pas restaurer votre commit. En supposant que votre arbre de travail et / ou votre index sont intacts, vous pouvez essayer un git reset --soft(ou à défaut a git reset) du commit précédent, puis refaire le commit. Évitez toute opération qui modifie votre arbre de travail sa git checkout -fou git reset --hard.

J'ai eu un problème similaire suite à un écran bleu de la mort sur Windows 8.1

J'avais un fichier à cet endroit ...

C:\www\<project>\.git\refs\remotes\origin\<problem-branch>

Et il était vide alors que les autres fichiers de branche de ce dossier contiennent de longues chaînes.

NB je n'ai pas eu de changements / commits

• J'ai sauvegardé le <problem-branch> fichier
• Supprimé le fichier
• git fetch --all pour récupérer la branche

Ensuite, la complétion automatique de l'onglet a recommencé à fonctionner

S'il n'y a pas beaucoup de fichiers modifiés, je pense que le moyen le plus pratique de résoudre ce problème est:

1. sauvegarder les fichiers que vous avez modifiés dans le référentiel
2. supprimer votre dépôt existant
3. re-cloner à partir du serveur
4. collez les fichiers de l'étape 1 dans le référentiel, et git commit -a

J'ai réussi à résoudre ce problème en supprimant le fichier maître dans le répertoire git \ refs \ heads

Après un gel calculé et accident, ma branche git a été endommagé avec le message: git fatal: your current branch appears to be broken. Je ne pouvais rien faire.

Après avoir fait git fsckmentionné que la branche avait un fichier error: Invalid HEAD. refs/heads/<branch>avait un invalid sha1 pointer.

En suivant les options ici, j'ai ouvert .git/refs/heads/<branch>dans un éditeur notepad ++, et chacun des caractères sha1 l'était NUL.

Heureusement, je n'avais besoin que de réinitialiser la branche à l'état distant, et c'était sur un dépôt bitbucket. J'ai attrapé le sha1 de la pointe du repo distant et l' .git/refs/heads/<branch>ai copié dans le fichier enregistré, puis j'ai fait un git reset --hard HEAD, et tout est revenu à la normale.

J'étais assez idiot pour oublier de pousser et mon ordinateur s'est écrasé lors d'un commit. Je pourrais tout récupérer sauf le dernier commit en ouvrant .git / logs / refs / heads /

Ce fichier contient tous les commits (avec leurs SHA) dans la branche, ce que j'ai fait pour récupérer était:

• Sauvegarder les dernières modifications dans un dossier temporaire
• passer à une "table rase"
  • git checkout master
  • git reset --hard
• extraire l'avant-dernier commit dans le journal
• créer une branche à partir de cette tête détachée
• POUSSER
• Restaurer les dernières modifications
• S'engager à nouveau

Donc même lorsque vous faites une erreur stupide, vous n'êtes pas immédiatement repris par une journée entière de travail avec git :)

Je sais que c'est une réponse trop tardive, mais j'obtenais cette erreur parce que je n'avais pas de fichier origin/head. Vous pouvez le découvrir en exécutant git branch -r. Si vous ne voyez pas votre origin/headpointage vers une origine distante, vous pouvez le définir en exécutant git remote set-head origin {{your branch name}}.

Maintenant, exécutez à git branch -rnouveau, et vous devriez voir quelque chose comme ceci: origin/HEAD -> origin/develop

J'espère que cela aidera quiconque rencontre ce problème.

Je n'ai pas pu vérifier ma branche principale en raison de l'erreur de référence impossible à verrouiller. J'ai fini par supprimer: .git/refs/remotes/origin/HEAD .git/refs/remotes/origin/master

et en appelant cette commande git:

git fetch --all

Pardonnez-moi si je répéterais après quelqu'un (je n'ai pas lu tous les commentaires). À mon avis, le moyen le plus simple de résoudre le problème est de copier le projet sans .git et .idea, de le nettoyer, de le cloner à partir de git, de tout supprimer sauf les répertoires ci-dessus, puis de coller la copie précédente dans le repo nouvellement créé avec .git et .idea . J'espère que cela a du sens.

Mon ordinateur a planté deux fois et par conséquent, mon référentiel git a été cassé localement. Je n'ai pas pu extraire mes modifications, il a demandé de définir l'origine distante mais cela n'a pas fonctionné dans gitKraken.

Sur mon invite de commande, j'obtenais cette erreur

Je savais que mes références sont brisées et doivent être corrigées. Ce que je devais faire, c'est git bash (dans SourceTree, cliquez sur "terminal"). Ensuite, accédez au dossier de références comme celui-ci

cd .git
cd refs
cd remotes
cd origin

il y aura un nom de fichier masterlà-bas, utilisez lspour voir ce qu'il y a dans le répertoire. Ensuite, supprimez-le simplement en utilisant rm master

bam, le fichier corrompu a disparu. Maintenant, si vous lancez la commande git branch -a, cela affichera ceci

$ git branch -a
* master
  remotes/origin/master (this in red color -scary :) )

Puis émettez cette commande, et elle corrigera vos références

$ git remote set-head origin master

Pour résumer, si vous essayez de retirer la télécommande, elle devrait afficher le nom de la télécommande vide qui a été corrigé.

J'ai eu le même problème mais pas de chance, je n'ai pas pu comprendre le problème. J'ai pris mon dépôt de côté, re-cloné celui du serveur et essayé de fusionner entre eux. Bien sûr, il montrait beaucoup de fichiers non liés à ma branche, mais aidait à isoler les fichiers requis.

Vérifiez si MSWindows a créé des fichiers desktop.ini qui sont à la fois le git? ça fait pour moi. Une fois que je les ai tous supprimés dans les sous-dossiers du répertoire .git, cela fonctionne.

J'ai eu ce même problème lorsque Android Studio s'est arrêté soudainement (en raison d'une perte d'alimentation de l'ordinateur).

Je l'ai résolu en copiant le contenu de mon C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\heads\masterfichier dans mon C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\refs\remotes\origin\masterfichier.

(Auparavant, j'avais également activé l'option 'Force Push' dans Android Studio, mais je ne pense pas que ce soit une étape nécessaire.)

Remarque:

J'ai trouvé cette solution en comparant le contenu des fichiers de mon C:\Users\myusername\AndroidStudioProjects\MyBrokenApp\.git\répertoire (sous-répertoires inc.) Aux fichiers correspondants de ceux d'un autre projet sain - par exemple,C:\Users\myusername\AndroidStudioProjects\MyHealthyApp\.git\ .

Vous pouvez avoir un fichier différent qui est corrompu, mais en comparant avec un autre projet sain, vous devriez être en mesure de repérer rapidement ce qui ne va pas.

Si vous n'avez pas d'autre projet sain sur lequel git est configuré, il peut être intéressant d'en créer un simple de la même manière que vous avez créé votre projet cassé afin de pouvoir enquêter, comparer et corriger, etc.

PS - Mon message d'erreur (modifié) était: warning: ignoring broken refs/remotes/origin/master.fatal bad revision 'refs/remotes/origin/master..refs/heads/master' during executing git -c core.quotepath=false log refs/remotes/origin/master..refs/heads/master --pretty=format --encoding=UTF-8 -M --name-status -c --