Re: Deprecation/Removal schedule

["Shawn O. Pearce" <spearce@spearce.org>]

Alex Riesen <raa.lkml@gmail.com> wrote:
> I have reflog off by default (and never missed it yet), so leave it
> at least as option to git-fsck, please. Besides, how do you find
> lost objects which were not mentioned in any reflog? (because
> of a bug someone made in reflog code, for example)

Learn to love reflog.  :-)

I use it daily.  Mainly `git log origin/master@{1}..origin/master`
to see what has come in from Junio since my last fetch.  The @{n}
syntax has (for me) been one of its best features.  (Thanks Junio!)

Repeat after me:

  There aren't any bugs in the reflog code.
  They have not been any bugs in the reflog code.
  There will never be any bugs in the reflog code.

I don't think we've had a case where a commit wasn't recorded in
a reflog when it should have been.  Perhaps *very* early in reflog
development a couple of commands bypassed the reflog code, but that
has certainly since been fixed.  The last one was git-receive-pack,
which we finished in early December.

If the reflog code did fail to record something, and you needed it,
and you hadn't git-prune'd yet, git-fsck would list the dangling
commit.  And a copy-n-paste session with `git-log -p D --not --all`
in another xterm would help you navigate what the dangling commits
were.

-- 
Shawn.