Annulation de git reset --hard avec des fichiers non validés dans la zone de transit

Question

J'essaie de récupérer mon travail. J'ai bêtement fait git reset --hard mais avant cela, je n'ai fait que get add . et n'a pas fait git commit . Aidez-moi ! Voici mon journal :

MacBookPro:api user$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)

#   modified:   .gitignore
...

MacBookPro:api user$ git reset --hard
HEAD is now at ff546fa added new strucuture for api

Est-il possible d'annuler git reset --hard dans cette situation ?

Answer 1

Les solutions ci-dessus peuvent fonctionner, cependant, il existe des moyens plus simples de récupérer de cela au lieu de passer par git -s complexe undo. Je suppose que la plupart des git-resets ne concernent qu'un petit nombre de fichiers, et si vous utilisez déjà VIM, cette solution la plus efficace en termes de temps. L'inconvénient est que vous devez déjà utiliser ViM's persistent-undo, que vous devriez utiliser de toute façon, parce que il vous donne la possibilité d'annuler un nombre illimité de changements.

Voici les étapes :

1. Dans vim, appuyez sur : et tapez la commande set undodir . Si vous avez persistent undo activé dans votre .vimrc le résultat sera similaire à undodir=~/.vim_runtime/temp_dirs/undodir .

2. Dans votre repo, utilisez git log pour connaître la dernière date/heure à laquelle vous avez effectué la dernière commettre

3. Dans votre shell, naviguez vers votre undodir en utilisant cd ~/.vim_runtime/temp_dirs/undodir .

4. Dans ce répertoire, utilisez cette commande pour trouver tous les fichiers que vous avez modifiés depuis la dernière livraison

   find . -newermt "2018-03-20 11:24:44" \! -newermt "2018-03-23" \( -type f -regextype posix-extended -regex '.*' \) \-not -path "*/env/*" -not -path "*/.git/*"

   Ici, "2018-03-20 11:24:44" est la date et l'heure de la dernière livraison. Si la date à laquelle vous avez effectué la git reset --hard est "2018-03-22", alors utilisez "2018-03-22", puis "2018-03-23". Ceci est dû à une bizarrerie de find, où la limite inférieure est inclusive, et la limite supérieure est exclusive. https://unix.stackexchange.com/a/70404/242983

5. Ensuite, allez dans chacun des fichiers, ouvrez-les dans vim, et faites un "earlier 20m". Vous pouvez trouver plus de détails sur "earlier" en utilisant "h earlier". Ici earlier 20m signifie revenir à l'état du fichier 20 minutes en arrière, en supposant que vous avez fait le git hard --reset 20 minutes de retour. Répétez ceci sur tous les fichiers qui sont sortis de l'ordinateur. find commande. Je suis sûr que quelqu'un peut écrire un script qui combinera ces choses.

Answer 2

J'utilise IntelliJ et j'ai pu simplement parcourir chaque fichier et le faire :

Edit -> reload from disk

Heureusement, je venais de faire un git status juste avant d'effacer mes modifications de travail, donc je savais exactement ce que je devais recharger.

Answer 3

Se souvenir de la hiérarchie de vos fichiers et utiliser la technique de Mark Longair avec la modification de Phil Oakley donne des résultats spectaculaires.

Essentiellement, si vous avez au moins ajouté les fichiers au dépôt mais que vous ne les avez pas validés, vous pouvez les restaurer en utilisant interactivement la commande git show Dans le cas d'un fichier de données, inspectez le journal et utilisez la redirection du shell pour créer chaque fichier (en vous souvenant de votre chemin d'intérêt).

HTH !

Answer 4

Je n'ai pas été en mesure de récupérer le fichier en utilisant les commandes git. Dans mon cas, c'était un fichier CPP. Je connaissais une chaîne unique dedans et ce aidé. La commande est :

sudo grep -a -B[number of rows before the text being searched] -A[number of rows after the text being searched] '[some unique text in the lost file]' /dev/sda3 > test.cpp

Il fouille tout le disque mais finit par retrouver le contenu du fichier perdu.