Jeff King <peff@xxxxxxxx> wrote: > This limit doesn't seem to come into effect anywhere else; it's simply > an arbitrary limit to make memory allocation easier. It's used to > declare a single static array of 20-byte hashes, so this increase wastes > about 2K. I don't really see a problem with this, however: The pack v4 code that Nico and I are working on was planning on taking a very useful optimization for any commit with less than 64 parents (or maybe 128, I'd have to go back to look at my notes). We would fall back to a less optimal storage for these large octopus commits. Of course the fallback strategy (which is really just the current OBJ_COMMIT packing) is still more space efficient than making multiple commits to express the octopus, so pushing this limit up higher would save space better. Oh, and these types of octopus merges aren't very frequent either. ;-) git-bisect can bisect these large octopuses, but it needs to search every parent commit in the merge. It cannot perform a binary search through them. Getting massive octopuses makes it harder for the user to bisect. I'm thinking maybe this should just change to a dynamic allocation and let the caller feed however many parents they want. Most people don't make an octopus very often, and when they do they really mean to do it, such as the case you just described. Unless Dscho/Nico/Junio/Linus/etc. know of some other limitation lurking within Git. My recollection is that only git-commit-tree and git-gui knew about this 16 parent limit. And the latter only knows about the limit so that can prevent the user from doing an octopus merge that overflowed git-commit-tree's limit. Be nice if git-gui has no limit. ;-) -- Shawn. - 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