Re: [RFC/PATCH] commit-tree: bump MAX_PARENTS to 128

["Shawn O. Pearce" <spearce@spearce.org>]

Jeff King <peff@peff.net> 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.