Re: Deprecation/Removal schedule

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

Alex Riesen <raa.lkml@gmail.com> wrote:
> 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.
 
> >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.