Re: Keeping unreachable objects in a separate pack instead of loose?

[Ted Ts'o <tytso@mit.edu>]

On Mon, Jun 11, 2012 at 04:44:29PM +0200, Thomas Rast wrote:
> 
> Starting with v1.7.10.2, and in the v1.7.11-rc versions, there's a
> change by Peff: 7e52f56 (gc: do not explode objects which will be
> immediately pruned, 2012-04-07).  Does it solve your problem?

I'm currently using 1.7.10.2.552.gaa3bb87, and a "git gc" still kicked
loose a little over 4.5 megabytes of loose objects were not pruned via
"git prune" (since they hadn't yet expired).  These loose objects
could be stored in a 244k pack file.

So while I'm sure that change has helped, if you happen to use a
workflow that uses git rebase and/or guilt and/or throwaway test
integration branches a lot, there will still be a large number of
unexpired commits which still get kicked loose, and won't get pruned
for a week or two.

What I think would make sense is for git pack-objects to have a new
option which outputs a list of object id's which whould have been
kicked out as loose objects if it had been given the (undocumented)
--unpacked-unreachable option.  Then the git-repack shell script (if
given the -A option) would use that new option instead of
--unpacked-unreachable, and then using the list created by this new
option, create another pack which contains all of these
unreachable-but-not-yet-expired objects.

Regards,

						- Ted