On 2009-02-09, Nicolas Pitre <nico@xxxxxxx> wrote: > On Sun, 8 Feb 2009, Nick Quaranto wrote: >> http://gitready.com > > Well done. > > One topic that IMHO you fail to cover, and which is being neglected > almost everywhere else too, is the reflog. > > The reflog is really your safety net when working with git. It records > everything you do. So even if you screw up a rebase, perform the wrong > merge, or any other kind of undesired operation, then you may always go > back to a previous state. Either you use -g with 'git log' to see all > those recorded states, or even 'git reflog' without any argument to get > a condensed list for HEAD. > > The <branch>@{<spec>} notation can be used anywhere a ref is normally > required. The special branch "HEAD" shows every state the HEAD pointer > went through, including branch switches. The <branch< part can be left > out to mean "currently checked-out branch". > > One thing that I use all the time after a 'git pull' is 'git log @{1}..' > where "@{1}" means the first previous tip of the current branch, so > effectively showing me the log of what the pull brought in my branch. Also, the @{now} notation to get a relative timestamp of the reflog is invaluable. Seeing reflog lines annotated with '14 minutes ago' or '17 hours ago' or perhaps '4 days ago', really helps to focus on the commits you're looking for: git reflog show @{now} # (the 'show' is not optional in this syntax) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
