You will be much, much happier as a result the next time you drop something. Once you know about the reflog, it's virtually impossible to lose anything in a Git repo that you ever put into an actual commit, no matter what you do subsequently.
(The main exception is if you only realize you wanted it weeks after discarding it. By default Git does eventually garbage-collect commits that no refs point to.)
Posted Sep 12, 2012 21:03 UTC (Wed) by robert_s (subscriber, #42402)
[Link]
Thanks for this - will probably save me a lot of time.
Bazaar on the slow track
Posted Sep 12, 2012 23:43 UTC (Wed) by cesarb (subscriber, #6266)
[Link]
> Once you know about the reflog, it's virtually impossible to lose anything in a Git repo that you ever put into an actual commit, no matter what you do subsequently.
AFAIK, the reflog is deleted when the branch is deleted. So if it happened on a branch you later deleted, you just lost the reference and it is git fsck time.
I would prefer if it left the reflogs for deleted branches around, and garbage-collected them later.
Bazaar on the slow track
Posted Sep 12, 2012 23:55 UTC (Wed) by price (subscriber, #59790)
[Link]
Even when you delete a branch, the old commits will all still be in the reflog for HEAD (unless they're past the expiration time anyway -- or you delete HEAD itself, which is beyond the ken of normal Git commands.) So they'll still show up in 'git reflog show' (which refers to HEAD by default), and you can still recover them just fine.
I do agree that it would be better if Git kept the reflogs around. A case where this does matter is if you want to keep an archival record of changes to the repository, e.g. in a organization's central repository that everybody pushes to. It's simple to configure Git never to expire old reflog entries (see gc.reflogexpire and gc.reflogexpireunreachable in git-config(1)), but AFAIK there's no way to configure it to keep reflogs of deleted refs.