Re: [PATCH 1/3] repack: modify behavior of -A option to leave unreferenced objects unpacked

From: Nicolas Pitre <nico@cam.org>
Date: May 11, 2008, 01:10 UTC
Message-ID: <alpine.LFD.1.10.0805101157090.23581@xanadu.home>
In-Reply-To: <20080510060345.GC11556@sigill.intra.peff.net>

On Sat, 10 May 2008, Jeff King wrote:

> Also, should --keep-unreachable be deprecated / removed?

Depends. If it has no maintenance cost then we might as well keep it around.

> I still like Geert's suggestion of unpacking them to a _different_
> place. That helps to avoid spurious "gc --auto" invocations caused by
> too many prunable objects. Though it certainly doesn't solve it, and
> maybe that just needs to be fixed separately.

Having a separate location for objects seems clunky to me.

And the fundamental problem isn't solved indeed -- you may end up with many non expired unreachable loose objects already without packing them.

> Possibly the "gc --auto" test should be:
> 
>   - count objects; if too few, exit
>   - count unreachable loose objects; if too few, exit

Determining the number of unreachable objects is quite costly, packed or not. So that isn't a good thing to do on every 'git gc --auto' invokation.

Show 5 quoted lines

>   - run gc
> 
> That means having a lot of unreachable objects will still incur some
> extra processing, but not as much as a full repack. And it won't bug the
> user with a "you need to repack" message.

The auto gc performs incremental packing most of the time. And that is way faster than figuring out which objects are unreachable.

For example, running 'git prune' in my Linux repo takes 16 seconds, even when there is nothing to prune. Running 'git repack' (with no option so to perform an incremental repack) took less than 2 seconds to pack 541 reachable objects that happened to be loose.

I'm now starting to wonder if there is a reason for keeping unreachable objects that used to be packed. Putting --keep-unreachable aside for now, the only way an unreachable object could have entered a pack is if it used to be reachable before through the commit history or reflog. So if they're not reachable anymore, that's most probably because their reflog expired. So what's the point for keeping them even longer? What's the reasoning that led to the creation of --keep-unreachable in the first place?

Nicolas