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

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

On Mon, Jun 11, 2012 at 06:23:08PM -0400, Jeff King wrote:
> 
> I'm more specifically worried about large objects which are no better in
> packs than they are in loose form (e.g., video files). This strategy is
> a regression, since we are not saving space by putting them in a pack,
> but we are keeping them around much longer. It also makes it harder to
> just run "git prune" to get rid of large objects (since prune will never
> kill off a pack), or to manually delete files from the object database.
> You have to run "git gc --prune=now" instead, so it can make a new pack
> and throw away the old bits (or run "git repack -ad").

If we're really worried about this, we could set a threshold and only
pack small objects in the cruft packs.

> > One last thought: if a sysadmin is really hard up for space, (and if
> > the cruft objects include some really big sound or video files) one
> > advantage of labelling the cruft packs explicitly is that someone who
> > really needs the space could potentially find the oldest cruft files
> > and delete them, since they would be tagged for easy findability.
> 
> No! That's exactly what I was worried about with the name. It is _not_
> safe to do so. It's only safe after you have done a full repack to
> rescue any non-cruft objects.

Well, yes.  I was thinking it would be safe thing to do after a "git
gc" didn't result in enough space savings.  This would require that a
git repack always rescue objects from cruft packs even if the -a/-A
options are not specified, but since we're doing a full reachability
scan, that should slow down git gc much, right?

    					- Ted