Re: WARNING: THIS PATCH CAN BREAK YOUR REPO, was Re: [PATCH 2/3] Only repack active packs by skipping over kept packs.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Oct 30, 2006, 22:54 UTC
- Message-ID
- <7vbqntv2h5.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <7v3b95wjmg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Show 14 quoted lines
> Jan Harkes <jaharkes@cs.cmu.edu> writes: > >> 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.