Junio C Hamano <junkio@xxxxxxx> writes: > Jan Harkes <jaharkes@xxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html