From: Shawn O. Pearce Date: Mon, 05 Feb 2007 19:45:08 GMT Subject: Re: Deprecation/Removal schedule Message-ID: <20070205194508.GD8409@spearce.org> In-Reply-To: <81b0412b0702050750m5760ce61le34acc8adfdb8081@mail.gmail.com> Alex Riesen 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.