Re: [PATCH] Fix read-tree merging more than 3 trees using 3-way merge

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 15 Aug 2007, Junio C Hamano wrote:
>
> For multi-base merges, we allowed read-tree -m to take more than
> three trees (the last two are our and their branches, and all the
> earlier ones, typically one but potentially more, are used as the
> merge base).  Unfortunately, the conversion done by commit 933bf40
> broke this.

Sorry. I didn't even realize people did this. Oops.

I note that the thign you committed limited the number of trees to 4. 
May I suggest this patch in addition to your patch? Also, is 4 actually 
the real maximum? Maybe it should be raised?

What *is* the behaviour for four trees? Reading "unpack_trees()" source 
implies that all other trees go into stage 1, where the first matching 
entry is used?

		Linus

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

diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index f6764b9..d5f849b 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -21,7 +21,7 @@ static int list_tree(unsigned char *sha1)
 {
 	struct tree *tree;
 
-	if (nr_trees >= 4)
+	if (nr_trees >= MAX_TREES)
 		return -1;
 	tree = parse_tree_indirect(sha1);
 	if (!tree)