Monthly Archives: October 2016

original source : http://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html

We’ve covered the reflog command briefly in a previous article on how to restore lost commits but it was never fully explained. Today we’ll look into what it does and how you can use it as a safety net to recover your work.

Once again the man pages are pretty terse about what this command actually does:

git-reflog – Manage reflog information

This definition is a little better, from later in the document:

Reflog is a mechanism to record when the tip of branches are updated. This command is to manage the information recorded in it.

Basically every action you perform inside of Git where data is stored, you can find it inside of the reflog. Git tries really hard not to lose your data, so if for some reason you think it has, chances are you can dig it out using git reflog. What this means is that you can use it as a safety net: you shouldn’t be worried that a merge, rebase, or some other action will destroy your work since you can find it again using this command.

The most common usage of this command is that you’ve just done a git reset and moved your HEAD back a few commits. But oops, you need that bit of code you left in the second commit. Crap. Now what? Running git reflog will probably result in something like this:

What this shows is a list of commits that Git still has in its storage. The first 7 characters are the beginning of the commit’s SHA1 hash, followed by the commit’s pointer, action, and message. You can see that not just commits are listed: switching branches, merges, rebases, and more are shown. The important part is the commit pointer and the SHA1: once you have that, you can do a git show to see the diff, or perhaps a checkout, cherry-pick, or merge depending on how you want to get the change back into your history.

You can also use the --all option to get more detailed information about different branches and even the stash:

This command is also used for another purpose: deleting old entries that you won’t need anymore. This may be done to conserve space in your repository, or perhaps since you want to take out the garbage every once in a while. You could knock off individual reflogs using the delete subcommand, but the expire subcommand is much more useful since it can be given a date to remove entries from.

An example of using this command to quickly pack up your repository can be found onJohn Wiegley’s post on Diving into Git, where he compresses his repository with the following commands:

$ git reflog expire --expire=1.minute refs/heads/master
$ git fsck --unreachable      
$ git prune                   
$ git gc                      

Basically this removes all reflogs that are older than a minute for the master branch, finds and deletes any commits that aren’t being used, then does some general cleanup on the whole repository to further compress it. This could have had its own tip, but it’s probably better to illustrate a great use of the subject’s subcommands in your workflow.

As always, check out the manpage for the other options, and if you have other uses for this command let us know!

original source : http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html

So, you just did a git reset --hard HEAD^ and threw out your last commit. Well, it turns out you really did need those changes. You’ll never be able to implement that algorithm that perfectly twice, so you need it back. Don’t fear, git should still have your commit. When you do a reset, the commit you threw out goes to a “dangling” state. It’s still in git’s datastore, waiting for the next garbage collection to clean it up. So unless you’ve ran a git gc since you tossed it, you should be in the clear to restore it.

For these examples, I’m working with the code for this blog. From the top, we just ran:

$ git show-ref -h HEAD
  7c61179cbe51c050c5520b4399f7b14eec943754 HEAD

$ git reset --hard HEAD^
  HEAD is now at 39ba87b Fixing about and submit pages so they don't look stupid

$ git show-ref -h HEAD
  39ba87bf28b5bb223feffafb59638f6f46908cac HEAD

So our HEAD has been backed up by one commit. At this point if we wanted it back we could just git pull, but we’re assuming that only our local repository knows about the commit. We need the SHA1 of the commit so we can bring it back. We can prove that git knows about the commit still with the fsck command:

$ git fsck --lost-found
  [... some blobs omitted ...]
  dangling commit 7c61179cbe51c050c5520b4399f7b14eec943754

You can also see the that git knows about the commit still by using the reflogcommand:

$ git reflog
  39ba87b... HEAD@{0}: HEAD~1: updating HEAD
  7c61179... HEAD@{1}: pull origin master: Fast forward
  [... lots of other refs ...]

So, we now have our SHA1: 7c61179. If we want to get immediately apply it back onto our current branch, doing a git merge will recover the commit:

$ git merge 7c61179
  Updating 39ba87b..7c61179
  Fast forward
    css/screen.css |    4 ++++
    submit.html    |    4 ++--
    2 files changed, 6 insertions(+), 2 deletions(-)

This command will bring your lost changes back and make sure that HEAD is pointing at the commit. From here you can continue to work as normal! You could also checkout the SHA1 into a new branch, but really a merge is the fastest and easiest way to restore that lost commit once you have the hash. If you have other ways let us know in the comments!

If you want some more options on what to do in this situation, Mathieu Martin’sillustrated guide to recovering lost commits with Git has plenty for you.