Re: Deprecation/Removal schedule

["Alex Riesen" <raa.lkml@gmail.com>]

On 2/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> 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.

git gc (repack -d of it) is too dangerous in a shared repo: it breaks
the repos which depend on the master repository, have sent (by some
means) some objects over to the master, and accidentally removed
the reference, and were pruned afterwards.
I'm not saying git gc is bad, I'm just saying you can't use it
whenever and wherever you want. Sometimes you'd prefer
to only expire logs, only pack refs or only repack. And if I
have no logs, I can't forget to trim them.

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

No, I can't. git gc and reflog --expire can. I have to call them.
And I don't think trimming the logs automatically is a good
idea: 90 days of commits can be a very long file on a busy repository.
Add to that slow disks and stupid OS (the worst case, which matters),
and you get a very annoyed user (if he was just angry before, having
to use the drive and OS, he'll definitely go berserk now).

> > >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.

Never had that, can be hardware problem.

What I meant is that it takes too long and I just avoid running
fsck unless I am forced to.