Junio C Hamano <junkio@xxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> writes: > > > I just spent some time bisecting this issue and it looks like the > > following change by Junio may be the culprit: > > > > commit 1d6b38cc76c348e2477506ca9759fc241e3d0d46 [snip] > Unfortunately, that is not the same hash we use in v1.3.0, so we > need to look elsewhere for interactions. Pity. Then either bisect goofed or there was a goof in meatspace while using bisect. I honestly expected bisect to point at the problem commit. I tried reverting 1d6b38cc but it didn't apply cleanly and I didn't feel like working through all of the conflicts at the time. [snip] > The earlier observation by Linus on reverting eeef7135 is > consistent with it; that commit was the one that introduced > v1.3.0 hash. Yet reverting that didn't help either. [snip] > You could try this patch to resurrect the hash used in v1.2.3, > and you may get better packing for your particular repository; > but I am not sure if it gives better results in the general > case. I am running the test myself now while waiting for my > day-job database to load X-<. [snip] Nope. When applied to 'next' it didn't help very much: Total 46391, written 46391 (delta 6466), reused 38662 (delta 0) 118M pack-7f766f5af5547554bacb28c0294bd562589dc5e7.pack Just to note: the 1.3.0 packer is saving 1M in the GIT repository over the 1.2.3 packer. So for a real project it does seem to have some benefit. And if you benchmarked the 1.3.0 packer against the Linux kernel and found it to be better than the 1.2.3 packer that's even better. I think this repository of mine may just be a degenerate case which GIT doesn't pack very well. GIT can't be all things to all people! -- Shawn. - : 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