I do not have a specific problem at hand, but I have encountered in the past some cases where I accidentally blew up my index, and wished I could go back the the previous state of a given file, which was indexed at some point.
Some example cases are :
$ 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 could resort to digging through git fsck --full --unreachable --no-reflog (as suggested here), I was wondering if there was a more convenient way to do this.
Question :
Is there some kind of reflog for the index ?
The reflog contains entries for refs...not the index.
But, perhaps a workflow tweak is the answer here...(it was for me).
If working on something that will take more than 5-10 minutes, commit-as-you-go (and cleanup prior to pushing). Otherwise, stage-as-you-go.
The index is great...I use it all day long! But I only really use it if I know that I will be commiting within just a minute or two (basically an atomic workflow operation). This is because I am scared that I will do something stupid and blow away my index.
While I am working, every time I reach a little milestone I make a private commit that usually will not be pushed until I've had a chance to do some cleanup first. I keep on commiting as I work on that specific problem, usually amending.
Then, once I've actually reached a stable point where I want to create a public commit I squash (if needed) all my little wip commits together, give a nice commit message and push.
This gives the huge advantage of creating little breadcrumbs in my reflog if needed.
Here's my 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!
This may seem like a lot of typing, but if you get good at flying on the shell (taking advantage of set -o emacs or set -o vi is a good way) then this approach becomes almost instant.
If what I'm working on truly is a very quick fix I will typically just use the stage-as-you-go approach, but anything longer than that I need the safety of populating my reflog as I go.
No, there is no reflog for the index. you will have to work our way around as you figured out with the git fsck with or without the --lost-found flag to the command.
You can use the timestamp of the files (SHA-1) to "sort" the files by the creation date and have some basic reflog based upon file creation time.
