Alex Riesen <raa.lkml@xxxxxxxxx> 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.
-
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