Re: dangling commits and blobs: is this normal?

[Nicolas Pitre <nico@cam.org>]

On Wed, 22 Apr 2009, Brandon Casey wrote:

> 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