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

[Nicolas Pitre <nico@cam.org>]

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.

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