Parcourir les commits orphelins dans Git

Mon repository git est en quelque sorte devenu cahoteux – j’ai chargé msysgit ce matin et au lieu que le nom de la twig soit affiché après le répertoire en cours, il indique “((ref: re …))”, “git status” nouveau fichier, ‘git log’ et ‘git reflog’ me disent “fatal: mauvaise révision par défaut ‘HEAD'”, et ainsi de suite.

Faire ‘git reflog –all’ ou ‘gitk –all’ me montre que le rest du repository est intact, mais il semble que la twig sur laquelle je travaillais vient de disparaître, ce qui explique pourquoi HEAD ne semble pas exister / pointez sur n’importe quoi.

Je sais que git garde toutes sortes de globes d’informations, et je suppose que mes commits viennent d’être orphelins d’une manière ou d’une autre, alors y at-il une commande qui me montrera ces commits pour pouvoir leur redonner HEAD?

EDIT: Oh mon cher. J’ai découvert ‘git fsck’, et ‘git fsck –full’ signale “fatal: l’object 03ca4 … est corrompu”. Qu’est-ce que je peux faire à ce sujet?

EDIT: Oh mon cher, mon cher. J’ai vérifié une autre twig, puis j’ai essayé de recréer la twig d’origine avec le même nom en utilisant l’erreur ‘git checkout -b lostbranchname’ et git says ‘: impossible de résoudre les références refs / heads / lostbranchname: verrouiller la référence pour la mise à jour: aucune erreur “. “Aucune erreur” doit être une erreur particulièrement méchante. On dirait donc qu’il traîne toujours, mais qu’il est impossible de l’utiliser ou de le tuer.

EDIT: Super duper, mon cher. J’ai fait un tas de déballage et de reconditionnement et de remplacement de choses comme suggéré ici: Comment récupérer des objects Git endommagés par une panne de disque dur? , mais maintenant, je reçois un autre hash signalé comme corrompu, pour quelque chose d’aussi inoffensif que le «statut git». Je pense que tout est arrosé. Git est adorable et tout, mais je ne devrais pas avoir à gérer ce genre de choses.

Plutôt que de laisser cela ouvert, je pense que je vais répondre à ma propre question. L’utilisation de git reflog --all est un bon moyen de parcourir les commits orphelins – et d’utiliser les hachages SHA1 pour reconstruire l’historique.

Dans mon cas cependant, le repository était corrompu, donc cela n’a pas aidé; git fsck peut vous aider à trouver et parfois à corriger des erreurs dans le référentiel lui-même.

Avec git 2.9.x / 2.10 (Q3 2016), vous n’aurez plus à utiliser git reflog --all plus, git reflog sera suffisant.

Voir commit 71abeb7 (03 juin 2016) par SZEDER Gábor ( szeder ) .
(Fusionné par Junio ​​C Hamano – gitster – dans commit 7949837 , 06 juil. 2016)

reflog : continuez à marcher sur le compte à reflog

Si un référentiel contient plus d’un commit racine, son reflog HEAD peut contenir plusieurs “événements de création”, c’est-à-dire des entrées dont la valeur “from” est la valeur sha1 nulle.
La liste d’un tel reflog s’arrête actuellement prématurément à la première de ces entrées, même si le renvoi contient encore des entrées plus anciennes.
Cela peut faire peur aux utilisateurs en leur faisant croire que leur refonte a été tronquée après « git checkout --orphan ».

Continuez à parcourir le reflog au-delà de ces événements de création en fonction de la “nouvelle” valeur de l’entrée de reflog précédent.

Une bonne caractéristique de git est qu’il détecte la corruption. Cependant, cela n’inclut pas la correction des erreurs pour protéger contre la corruption.

J’espère que vous avez poussé le contenu de ce référentiel sur une autre machine ou que vous avez des sauvegardes pour récupérer les parties corrompues.

Je n’ai aucune expérience avec git sur windows mais je n’ai jamais vu ce genre de comportement avec git sous Linux ou OS X.