Re: Deprecation/Removal schedule

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 5, 2007, 19:45 UTC
Message-ID: <20070205194508.GD8409@spearce.org>
In-Reply-To: <81b0412b0702050750m5760ce61le34acc8adfdb8081@mail.gmail.com>

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.