Re: dangling commits and blobs: is this normal?

From: Nicolas Pitre <nico@cam.org>
Date: Apr 22, 2009, 20:00 UTC
Message-ID: <alpine.LFD.2.00.0904221548310.6741@xanadu.home>
In-Reply-To: <FcecxnoVg4H8G3MKjZgl2T6zCGDer4yYyScIgaweFTNgDCKG65Xiig@cipher.nrlssc.navy.mil>

On Wed, 22 Apr 2009, Brandon Casey wrote:

Show 15 quoted lines

> Nicolas Pitre wrote:
> > On Wed, 22 Apr 2009, Brandon Casey wrote:
> 
> >> I've often wondered whether a plain 'git gc' should adopt the behavior
> >> of --auto with respect to the number of packs.  If there were few packs,
> >> then 'git gc' would do an incremental repack, rather than a 'repack -A -d -l'.
> > 
> > Why so?  Having fewer packs is always a good thing.  Having only one 
> > pack is of course the optimal situation.  The --auto version doesn't do 
> > it in the hope of being lightter and less noticeable by the user.
> 
> The only reason for avoiding packing all packs into one would be speed in
> this case also.  I recall reading complaints or surprise about gc
> repacking all packs into one, so I'm only trying to think about how to
> match program behavior with user expectations.

It's user's expectations that need adjusting then. Making a single pack is indeed the job of an explicit gc invocation.

> gc does a lot already, and even Jeff wasn't sure what to expect from 
> 'git gc' with respect to packs.  Possibly an acceptable trade off 
> between speed and optimal packing would be to adopt the --auto 
> behavior for deciding when to use '-A' with repack.

And what would be the point of manually running 'git gc' then, given that 'git gc --auto' is already invoked automatically after most commit creating commands?

I mean, if you consider explicit 'git gc' too long, then simply wait until you can spare the time, if at all. This is not like a non gc'd repository suddently becomes non functional.

WRT trade offs, the current behavior is already a pretty good compromize between speed and optimal packing, the later implying -f to 'git repack' which is far far slower.

Nicolas