Re: [PATCH] Fix read-tree merging more than 3 trees using 3-way merge
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Aug 17, 2007, 00:59 UTC
- Message-ID
- <alpine.LFD.0.999.0708161750550.30176@woody.linux-foundation.org>
- In-Reply-To
- <7vbqd8o1qs.fsf@gitster.siamese.dyndns.org>
On Wed, 15 Aug 2007, Junio C Hamano wrote:
Show 6 quoted lines
> > 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)