Réparer un dépôt git corrompu

ma solution pour une situation similaire était de remplacer un hachage de l'objet endommagé dans .git/refs/heads/my-working-branch par un hachage de commit précédent (qui peut être trouvé dans .git/logs/HEAD ).

ça m'est arrivé. Je referme le dépôt dans un nouveau dossier et déplace mes dernières modifications manuellement. Low tech mais qui fonctionne à chaque fois. J'espère que vous vous souviendrez de vos derniers changements.

pour moi, J'avais activé TRIM dans OSX avec un SSD non-Apple (ce qui n'est pas recommandé) et apparemment causé diverses corruptions sur mon disque de démarrage. Donc, le corrompu commettre était profonde dans l'histoire.

Je ne me soucie pas trop de réparer mon repo, sauf que j'ai quelques branches locales qui étaient trop expérimentales pour prendre la peine de pousser à la repo à distance, et je voudrais sauver le travail dans ces branches.

théoriquement, puisqu'il s'agit d'un local repo, je pense que git devrait être en mesure de récupérer/se réparer en utilisant l'origine. Pourquoi n'est-ce pas possible?

en tout cas, je suis tombé sur cette stratégie cool pour pousser une branche à une autre git repo locale. malheureusement, le clonage de la prise en pension dans ../repo_copy et ensuite en utilisant cela comme une télécommande locale a abouti à l'erreur suivante:

! git push --force local_remote HEAD
fatal: failed to read object e0a9dffddeeca96dbaa275636f8e8f5d4866e0ed: Invalid argument
error: failed to push some refs to '/Users/steve/Dev/repo_copy'

donc j'ai commencé avec un repo vide, puis en poussant des branches à elle a bien fonctionné. Si pour n'importe quelle branche locale j'ai eu dont le git log ne s'est pas terminé par:

....
    Fixing cukes
fatal: failed to read object e0a9dffddeeca96dbaa275636f8e8f5d4866e0ed: Invalid argument

je voudrais simplement vérifier et ensuite faire git push --force local_remote HEAD . La dernière chose que j'ai faite était:

! cd ~/Dev/repo_copy
! git remote add origin git@github.com:sdhull/my_repo.git  # real remote

puis je suis allé à git config -e et mis en place ma branche principale et a été de retour en cours d'exécution avec rien perdu! Laissez-moi savoir dans les commentaires si vous voulez plus de détails sur cette approche. Acclamations!

essayez de faire une sauvegarde du dépôt puis d'exécuter git reset --hard HEAD@{1} pour revenir au précédent HEAD et voir si cela fonctionne. C'est peut-être juste le courant HEAD qui est corrompu.

(vous devriez aussi lancer fsck sur votre disque si vous ne l'avez pas déjà fait.)

j'ai pu récupérer ma pension de:

zsh(broken)% git log master
error: object file .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395 is empty
error: object file .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395 is empty
fatal: loose object 7fcab8648a989d9bb3f5246e6be7220395493395 (stored in .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395) is corrupt
zsh(broken)% cat .git/refs/heads/master
7fcab8648a989d9bb3f5246e6be7220395493395
e311726c4eb970f4d4f504ad86248d322855018f da9c14d03e4849394087b61ff6272399937f7cce Nikolay Orliuk <virkony@gmail.com> 1379583764 +0300   commit: plan: timings

en réinitialisant master à prev commit da9c14d03e4849394087b61ff6272399937f7cce comme dit par @Nash Bridges:

zsh(broken)% echo da9c14d03e4849394087b61ff6272399937f7cce > .git/refs/heads/master
zsh(broken)% git log --oneline -1 master
da9c14d plan: timings
zsh(broken)% git fsck
Checking object directories: 100% (256/256), done.
error: object file .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5 is empty
error: object file .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5 is empty
fatal: loose object 0eace931fdc851da254e9522596d1517d0ed51c5 (stored in .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5) is corrupt

la Création de nouveaux vides repo, chercher master en rupture

zsh(broken)% mkdir ../recover && cd ../recover && git init
Initialized empty Git repository in /home/nikolay/talks/y/recover/.git/
zsh(recover)% git fetch ../broken master
remote: Counting objects: 44, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 44 (delta 20), reused 0 (delta 0)
Unpacking objects: 100% (44/44), done.
From ../broken
 * branch            master     -> FETCH_HEAD
zsh(recover)% git reset --hard FETCH_HEAD
HEAD is now at da9c14d plan: timings
zsh% git fsck
Checking object directories: 100% (256/256), done.

pour restaurer les changements qui étaient sur le chemin de master :

zsh(recover)% rm -rf * && cp -a ../broken/* ./          
zsh(recover)% git add -u && git commit -m 'prepare for publishing'

la solution la plus simple pour moi : vous pouvez git clone dans un nouveau dossier, puis remplacer le propre new_folder/.git à l'ancien dossier (le cassé dossier). Il fonctionne bien pour moi !

git clone ...(remote) new_folder
mv old_folder/.git  old_folder/.git_old
cp -R new_folder/.git  old_folder/

santé!

une autre alternative qui a fonctionné pour moi était de remettre la tête et l'index de git à leur état précédent en utilisant:

git reset --keep

j'ai aussi essayé les ordres suivants, mais ils n'ont pas fonctionné pour moi, mais ils ont pu pour vous:

git reset --mixed git fsck --full git gc --auto git prune --expire now git reflog --all

j'ai suivi les instructions trouvées ici

$ cd /tmp/
$ git clone good-host:/path/to/good-repo
$ cd /home/user/broken-repo
$ echo /tmp/good-repo/.git/objects/ > .git/objects/info/alternates
$ git repack -a -d
$ rm -rf /tmp/good-repo

a travaillé pour moi

j'ai eu le même problème et j'ai fait les étapes suivantes en utilisant git-repair

• cp myrepro myrepro.bak
• cd myrepro
• git repair --force (premier essai sans force ) Après cela a été couronné de succès l'arbre a été remis à la dernière commission de travail.

alors j'ai fait meld myrepro myrepro.bak pour appliquer les changements de l'arbre de travail du repro corrompu à la fixe repro.