Alex Riesen <raa.lkml@xxxxxxxxx> wrote:
> On 2/5/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> 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.
-
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