Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a reflog for the index?

Tags:

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 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 ?

like image 433
LeGEC Avatar asked Jul 06 '16 12:07

LeGEC


People also ask

What is git Reflog for?

Git keeps track of updates to the tip of branches using a mechanism called reference logs, or "reflogs." Many Git commands accept a parameter for specifying a reference or "ref", which is a pointer to a commit. Common examples include: git checkout.

What is the difference between git Reflog and log?

The biggest difference between Git reflog vs. log is that the log is a public accounting of the repository's commit history while the reflog is a private, workspace-specific accounting of the repo's local commits. The Git log is part of the Git repository and is replicated after a push, fetch or pull.

What is branch Reflog?

a reflog is a very special “branch” that records each position of HEAD in the last 30 days (by default). So removed branches won't be purged by prune until after waiting for 30 days, when the last reference to them will finally be released. reflog history is not shared – it is exclusive to your repository.

Does git push Reflog?

The reflog is strictly local and isn't part of the repository. It's also not included in pushes, fetches, or clones. Git uses the git reflog tool to keep track of changes made to branch tips. It lets you go back to any commit, even if it isn't referenced by any branch or tag.


1 Answers

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.

like image 51
Jonathan.Brink Avatar answered Nov 02 '22 05:11

Jonathan.Brink