Gibt es einen Reflog für den Index?

Question

Ich habe kein spezifisches Problem zur Hand, aber ich habe in der Vergangenheit einige Fälle erlebt, in denen ich versehentlich meinen Index in die Luft gesprengt habe und ich wünschte, ich könnte den vorherigen Zustand einer bestimmten Datei, die an einem bestimmten Punkt indiziert wurde, wiederherstellen .

Einige Beispielfälle sind:

$ git add <file> 
# find out that I already had an indexed version of <file>, 
# and that for some reason I shouldn't have added the extra modifications 

$ git stash pop 
# find out afterwards that I have a mix of "the index I had" 
# and "the index in the stash" 

$ git stash 
# with an active index, which is now mixed with the state of the working tree 

$ git reset <typo> 
# accidentally resetting the wrong file, or the whole directory 

One Graben durch git fsck --full --unreachable --no-reflog greifen könnte (wie here vorgeschlagen), frage ich mich, ob es ein bequemer Weg war, dies zu tun.

Frage:

Gibt es irgendeine Art von reflog für den Index?

Answer 1

Nein, es gibt keinen Reflog für den Index. Sie müssen sich so zurechtfinden, wie Sie es mit dem git fsck mit oder ohne --lost-found Flag für den Befehl herausgefunden haben.

Sie können den Zeitstempel der Dateien (SHA-1) verwenden, um die Dateien nach dem Erstellungsdatum zu "sortieren" und einen grundlegenden Reflog basierend auf der Erstellungszeit der Datei zu erstellen.

Answer 2

Der Reflog enthält Einträge für Refs ... nicht den Index.

Aber vielleicht ist ein Workflow-Tweak die Antwort hier ... (es war für mich).

Wenn die Arbeit an etwas, das mehr als 5-10 Minuten dauern, begehen-as-you-go (und vor Bereinigung drücken). Ansonsten stage-as-you-go. Die index ist großartig ... Ich benutze es den ganzen Tag lang! Aber ich benutze es nur wirklich, wenn ich weiß, dass ich innerhalb von ein oder zwei Minuten (im Grunde eine atomare Workflow-Operation) committen werde. Das liegt daran, dass ich Angst habe, dass ich etwas Dummes tun und meinen Index wegblasen werde.

Während ich arbeite, mache ich jedes Mal, wenn ich einen kleinen Meilenstein erreiche, ein privates Commit, das normalerweise erst dann gepusht wird, wenn ich die Möglichkeit hatte, etwas aufzuräumen. Ich beziehe mich weiter, während ich an diesem spezifischen Problem arbeite, das normalerweise geändert wird.

Dann, sobald ich tatsächlich einen stabilen Punkt erreicht habe, wo ich ein öffentliches Commit erstellen möchte, quetsche ich (wenn nötig) alle meine kleinen Wip-Commits zusammen, gib eine nette Commit-Nachricht und drücke.

Dies hat den großen Vorteil, dass bei Bedarf in meinem Reflog kleine Brotkrumen entstehen.

Hier ist mein Workflow:

# start work 
git checkout -b featurea 
# work 
vim file.txt 
# reach a little milestone 
git commit -a -m "working on feature..." 
# work some more 
vim file.txt 
# reach another little milestone 
git commit -a --reuse-message=HEAD --amend 
# work some more 
vim file.txt 
# another little milestone... 
git commit -a --reuse-message=HEAD --amend 
# finishing touches... 
vim file.txt 
# ok, done now, put everything back in working dir so I can review 
git reset HEAD~ 
# decide what goes in this commit 
# perhaps use `git add -p` 
git add file.txt 
# give a nice commit message (use editor) 
git commit 
# now merge to master and push with confidence! 

Dieses wie eine Menge Tipparbeit zu sein scheint, aber wenn man fliegen auf der Schale gut erhalten (Vorteil set -o emacs oder set -o vi Einnahme eine gute Art und Weise), dann dieser Ansatz wird fast augenblicklich.

Wenn das, woran ich gerade arbeite, eine sehr schnelle Lösung ist, verwende ich in der Regel nur die Stage-As-You-Go-Methode, aber alles, was länger ist, brauche ich die Sicherheit, meinen Reflog zu füllen.