Re: git-repack made my pack 317x larger...

From: Nicolas Pitre <nico@cam.org>
Date: Jun 15, 2007, 15:53 UTC
Message-ID: <alpine.LFD.0.99.0706151143590.5651@xanadu.home>
In-Reply-To: <20070615145433.22970.qmail@science.horizon.com>

On Fri, 15 Jun 2007, linux@horizon.com wrote:

Show 10 quoted lines

> >> Uh... what happened?  It's not a full kernel clone, but it's a lot more
> >> objects than I expected.  Where did all the extra objects come from?
> 
> > Maybe you want to add -l as well to your git-repack invocation.
> 
> Ah.  Thank you.  Indeed, this is another example of git documentation
> disease.  git-repack refers to git-pack-objects, which gives a very
> technical explanation of what it does, but nowhere is it mentioned that
> list of objects suppled to git-pack-object's stdin includes objects
> borrowed from alternates.

At some point it is necessary for people like you who are not so intimate with the packing code, and therefore to whom this doesn't look obvious, to raise those issues, and ideally provide patches.

> Given that "git-repack -f" is a not uncommon command, could I suggest
> that the default is wrong, and there should be a special flag for
> "suck in alternates, so this repository is no longer dependent
> on any others".

Well, I tend to disagree here. I don't think using -f _should_ be that common. It is a really expensive operation and you usualy should have a good reason to use it.

> Mentally, git-repack is a "reduce space consumption" command, not an
> increase one.  Having to remember that this repository uses alternates
> and add an extra flag to avoid having a space explosion is distinctly
> annoying.

Why don't you use git-gc then? Its mental model and actual implementation is really about reducing space, maybe even more than git-repack is, and it does call git-repack with -l.

Nicolas