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

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.
---
This limit is arbitrary; should it be ridiculously high (I think 128 is
already ridiculous, but we could go to 1024 and waste 20K). Or
should it simply allocate dynamically?

I ran into this while trying to make an octopus with 25 heads. I have a
set of 25 small repositories imported from CVS. They no longer see
active development, but I want to keep them around for historical
purposes. Checking out 25 repos is a pain, so I wanted to put them all
in one repo. However, I didn't just want the histories on separate
branches; I wanted everything checked out at once. So I did:

  rm -f .git/MERGE_HEAD
  for i in $repos; do
    git fetch ../$i $i
    git read-tree --prefix=$i/ $i
    git checkout -- $i
    git rev-parse $i >>.git/MERGE_HEAD
  done
  git commit

Which of course barfed on the giant octopus. Bumping up the limit
allowed it to happen with no visible problems (the history browsing code
works fine). Yes, I obviously could have done a series of 25 pair-wise
merges (or even 2 16-way octopus merges), but I think this more closely
represents what I'm trying to accomplish.

 builtin-commit-tree.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 2a818a0..48dbf1d 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c

@@ -60,7 +60,7 @@ static void check_valid(unsigned char *sha1, const char *expect)
  * Having more than two parents is not strange at all, and this is
  * how multi-way merges are represented.
  */
-#define MAXPARENT (16)
+#define MAXPARENT (128)
 static unsigned char parent_sha1[MAXPARENT][20];
 
 static const char commit_tree_usage[] = "git-commit-tree <sha1> [-p <sha1>]* < changelog";

-- 
1.5.0.1.793.gedfd5-dirty