Re: Strange merge conflicts against earlier merge.

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Nov 11, 2005, 23:33 UTC
Message-ID: <Pine.LNX.4.64.0511111806070.25300@iabervon.org>
In-Reply-To: <7vy83ukdwf.fsf@assigned-by-dhcp.cox.net>

On Fri, 11 Nov 2005, Junio C Hamano wrote:

Show 14 quoted lines

> Petr Baudis <pasky@ucw.cz> writes:
> 
> > 	16    anc1/anc2 anc1    anc2      no merge
> >
> > What ends up in the index at this moment as "stage 1"? anc1? anc2?
> > Two stage 1 entries? And what does git-merge-index do about this?
> 
> I think we decided there is no single sensible resolution, and
> we leave stage 1 empty.
> 
> Come to think of it, we should signal that we are punting by
> either exiting non-zero, or stuffing 0{40} SHA1 in stage1, so
> that we can distinguish the case with two sides adding things
> differently.  Daniel, what do you think?

Probably don't want to exit non-zero, since we can deal with the rest of the paths sensibly. All 0 SHA1 would work, if we want to identify this case. On the other hand, I think the desired behavior at present is to tell the user to pick the correct version of the two, which is the same as if it's new in both sides, which is why I had it like that.

Someday, we ought to do a combined merge-base and read-tree, which would be able to correctly handle revert wars, but it's too very exciting currently, since the multi-base merge cases have generally turned out to be user error (i.e., the user didn't actually mean to merge those things).

	-Daniel
*This .sig left intentionally blank*