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.