Re: [PATCH] repack: allow simultaneous packing and pruning

From: Eran Tromer <git2eran@tromer.org>
Date: Oct 10, 2006, 19:46 UTC
Message-ID: <452BF8B3.5090305@tromer.org>
In-Reply-To: <Pine.LNX.4.64.0610100800490.3952@g5.osdl.org>

On 2006-10-10 17:03, Linus Torvalds wrote:

Show 7 quoted lines

> On Tue, 10 Oct 2006, Sam Vilain wrote:
>> If using git-repack -a, unreferenced objects are kept behind in the
>> pack.  This might be the best default, but there are no good ways
>> to clean up the packfiles if a lot of rebasing is happening, or
>> branches have been deleted.
> 
> Don't do this.

Too late: "git repack -a -d" already does it, in contradiction to its manpage. It creates a new pack by following .git/refs, and then deletes all old pack files.

Show 6 quoted lines

> I understand why you want to do it, but the fact is, it's dangerous.
> 
> Right now, "git repack" is actually safe to run even on a repository which 
> is being modified! And that's actually important, if you have something 
> like a shared repo that gets re-packed every once in a while from a 
> cron-job!

Don't run it on a shared repo, then. And grab a coffee while it runs. But why force leaf repositories to accumulate garbage?

This functionality is just as racy, and just as necessary, as "git-prune". It merely garbage-collects the packs as well. Git seems to collect unreferenced objects faster than the space between the cushions in my sofa, and there ought to be a way to tidy up things.

Linus, I see why you neither need nor want this functionality in your typical workflow, but things look different for a downstream developer who engages in a variety of garbage-generating activities like tracking wild trees, rebasing patches and using stgit. I really don't need that unreferenced copy of 2.6.15-rc2-mm1 in my packs anymore.

  Eran