Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:29
Subsystem: the rest · Maintainer: Linus Torvalds

Possibly related (same subject, not in this thread)


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)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help