Re: [RFC PATCH] repack: make repack -a equivalent to repack -A and drop previous -a behavior

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Nov 14, 2008, 00:53 UTC
Message-ID: <jKWdt94ZxgNW0UAgUUW-qjTtpWohpQXMfvw-AUmOXND8SD5yFw0N8w@cipher.nrlssc.navy.mil>
In-Reply-To: <20081114000219.GB5285@atjola.homenet>

Björn Steinbrink wrote:

Show 22 quoted lines

> On 2008.11.13 17:22:36 -0600, Brandon Casey wrote:
>> Once upon a time, repack had only a single option which began with the first
>> letter of the alphabet.  Then, a second was created which would repack
>> unreachable objects into the newly created pack so that git-gc --auto could
>> be invented.  But, the -a option was still necessary so that it could be
>> called every now and then to discard the unreachable objects that were being
>> repacked over and over and over into newly generated packs. Later, -A was
>> changed so that instead of repacking the unreachable objects, it ejected
>> them from the pack so that they resided in the object store in loose form,
>> to be garbage collected by prune-packed according to normal expiry rules.
>>
>> And so, -a lost its raison d'etre.
>>
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>> ---
>>
>>
>> This is on top of bc/maint-keep-pack
> 
> I didn't check all the (proposed) commits for that branch, so just let
> me know if I'm missing anything, but doesn't this change mean that you
> just lose what "-ad" did?

yes.

> We have:
> 	-a	Create a new pack, containing all reachable objects
> 	-A	Same as -a
> 	-ad	Same as -a, and drop all old packs and loose objects

by loose objects, I assume you mean packed unreachable objects.

Show 9 quoted lines

> 	-Ad	Sama as -ad, but keep unreachable objects loose
> 
> -Ad is nice regarding it's safety-net value, but eg. after a large
> filter-branch run, when refs/original and the reflogs have been cleaned,
> you just want to get rid of all those old unreachable objects,
> immediately. For example after importing and massaging some large
> history from SVN, the -Ad behaviour is definitely _not_ what I want
> there. Writing a few thousand loose objects just to prune them is just a
> waste of time.

hmm. That's a good point. Even though I think it is likely that the thousand loose objects that are written will be small commit objects and not blobs, this use case may be enough to trump the safety benefit provided by the proposed change.

-brandon