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

[Eran Tromer <git2eran@tromer.org>]

On 2006-10-10 17:03, Linus Torvalds wrote:
> 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.

> 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