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)
-
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
