Re: dangling commits and blobs: is this normal?

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Apr 22, 2009, 19:26 UTC
Message-ID: <FcecxnoVg4H8G3MKjZgl2T6zCGDer4yYyScIgaweFTNgDCKG65Xiig@cipher.nrlssc.navy.mil>
In-Reply-To: <alpine.LFD.2.00.0904221331450.6741@xanadu.home>

Nicolas Pitre wrote:

> On Wed, 22 Apr 2009, Brandon Casey wrote:

Show 7 quoted lines

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

Show 5 quoted lines

> However the user manually invoking gc should be expecting some work is 
> actually happening.  If you don't want the whole repo read from one pack 
> just to be written in another pack (say the repo is huge and waiting 
> after the IO is not worth it) then just mark such a pack with a .keep 
> file.

That's true, but a user who knows about the .keep mechanism would also not be afraid to run 'repack -d -l' (I'm ignoring the other operations of gc).

-brandon