Re: WARNING: THIS PATCH CAN BREAK YOUR REPO, was Re: [PATCH 2/3] Only repack active packs by skipping over kept packs.

Junio C Hamano [off-list ref] writes:

Jan Harkes [off-list ref] writes:

quoted

The following patch does fix the problem Nicolas reported, but for some
reason I'm still getting only 102 objects (only tags and the commits
they refer to?) with your test.

One potential downside of this is that this makes an obscure but
useful "gitk --unpacked" useless (robs performance).

http://thread.gmane.org/gmane.comp.version-control.git/19197/focus=19207

But other than that, I think it is an Ok change.  The original
semantics of --unpacked (with or without "pretend as if objects
in this pack are loose") were, eh, "strange".

I changed my mind.

Even without --unpacked=pretend-this-is-loose nor .keep flag,
the original semantics of --unpacked and git repack do not play
with each other well.  You can have a history where you have a
pack in the middle of the history, and would expect "git repack"
without -a to make your .git/objects/??/ directories empty but
it would not because --unpacked has been defined to mean "stop
traversal when we hit a packed commit".  That would _not_
corrupt the repository, but is very counter-intuitive.

Unfortunately this is a semantic change in the middle of the
road (and it would change the _output_ not just performance of
"gitk --unpacked"), but I think it is a semantic change of a
good kind.

So I'll take Jan's patch as is.  It needs to go all the way down
to "maint", since we have --unpacked= there already.