Re: Strange merge conflicts against earlier merge.
- From
Petr Baudis <pasky@suse.cz>
- Date
- Nov 11, 2005, 17:32 UTC
- Message-ID
- <20051111173239.GU16061@pasky.or.cz>
- In-Reply-To
- <7v64qzozyx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Nov 11, 2005 at 06:29:10PM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that...
Show 6 quoted lines
> - The above turned out to have a risky corner case, especially > when one side reverted a patch and the other one did not. To > address this, read-tree was rewritten and 3-way form of > read-tree can take more than three trees these days, letting > you feed it all the merge base candidates. This code is used > in 'resolve' strategy.
Yes, but what I didn't find out is whether the additional trees result in additional stages, what are the trivial merging rules, how does it play together with git-merge-index, etc. Doesn't seem to be documented either.
Thanks,
-- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.