Re: Deprecation/Removal schedule

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 5, 2007, 22:55 UTC
Message-ID: <20070205225505.GA9222@spearce.org>
In-Reply-To: <81b0412b0702051449l3951ee43s34bde4614c83612d@mail.gmail.com>

Alex Riesen <raa.lkml@gmail.com> wrote:

Show 8 quoted lines

> On 2/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >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!)
> 
> It looks and smells like a useful feature. I just haven't found
> any use for it yet. Besides all the good, it's another part of a repo
> needing maintenance (constantly growing thing, like /var/log).

`git gc` is your friend. It automatically trims the reflogs, keeping only the last 90 days worth of entries. You can tune this with the `gc.reflogexpire` configuration parameter. Seeing as how `git gc` also invokes `git repack -a -d`, `git pack-refs --prune`, etc., one would have to wonder why use anything else.

So its not a constantly growing thing; you can at least bound it
by time.

Show 8 quoted lines

> >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.
> 
> Yes, of course. I somehow missed it. Shows how often one does
> git-fsck in cygwin, doesn't it?

:-)

Actually I have need for git-fsck too often on Cygwin; one of my coworkers looses objects all of the time in his repository. I think his harddrive is failed. The zlib CRC checking we put into pack-objects saved his bacon when it failed to repack his repository with corrupt objects.

-- 
Shawn.