Re: [RFC PATCH] repack: make repack -a equivalent to repack -A and drop previous -a behavior

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.11.13 18:53:29 -0600, Brandon Casey wrote:
> Björn Steinbrink wrote:
> > I didn't check all the (proposed) commits for that branch, so just let
> > me know if I'm missing anything, but doesn't this change mean that you
> > just lose what "-ad" did?
> 
> yes.
> 
> > We have:
> > 	-a	Create a new pack, containing all reachable objects
> > 	-A	Same as -a
> > 	-ad	Same as -a, and drop all old packs and loose objects
> 
> by loose objects, I assume you mean packed unreachable objects.

No, actually I just totally ignored the fact that -a of course already
deletes the loose objects. The packed unreachable objects are in the old
packs, so they're already included in the first half of my sentence ;-)

> > 	-Ad	Sama as -ad, but keep unreachable objects loose
> > 
> > -Ad is nice regarding it's safety-net value, but eg. after a large
> > filter-branch run, when refs/original and the reflogs have been cleaned,
> > you just want to get rid of all those old unreachable objects,
> > immediately. For example after importing and massaging some large
> > history from SVN, the -Ad behaviour is definitely _not_ what I want
> > there. Writing a few thousand loose objects just to prune them is just a
> > waste of time.
> 
> hmm. That's a good point. Even though I think it is likely that the thousand
> loose objects that are written will be small commit objects and not blobs,

When you only fix up merge commits, author information and such things,
then yes, most objects will be commits. And then it's not even that bad.

But a more interesting case is when in your old SCM you had multiple
projects in one repo, and you can't sanely separate them before the
import. So you might end up using the subdirectory filter a few times,
or even just drop a bunch of branches in each copy of your import.

And another one is when you had accidently commited some huge, useless
files, and as you're switching to git now anyway, you want to get rid of
them, so you use an index-filter to drop them.

For those two cases, -Ad vs -ad can make a huge difference. I remember
someone on #git using a subdirectory filter on some project and trying
to get the repo to a sane size afterwards. -Ad took basically forever,
while -ad finished in 5 seconds or so.

> this use case may be enough to trump the safety benefit provided by the
> proposed change.

IMHO, "git gc" already provides enough safety. I tend to see "gc" as the
regular "just use it" tool, while repack gives me more control over how
I want things to be done, without forcing me to use the real plumbing or
to fumble around with the configuration for gc. And when I want control,
I'm generally prepared to shoot myself in the foot.

Björn