Re: Strange merge failure (would be overwritten by merge / cannot merge)

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sep 6, 2009, 19:54 UTC
Message-ID: <alpine.LFD.2.01.0909061248470.8946@localhost.localdomain>
In-Reply-To: <7v3a6z3lsg.fsf@alter.siamese.dyndns.org>

On Sun, 6 Sep 2009, Junio C Hamano wrote:

Show 7 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > And then fix the fallout from that: callers never get mixed-up tree and 
> > blob entries, and have to do their DF checking themselves.
> 
> There are two levels of internal APIs involved, and I am getting confused
> as to which level of callers you are referrring to in the above.

It could be done at any level, but there's a few places where it's easier than others.

Show 6 quoted lines

> My understanding of the current situation is:
> 
>  * unpack_trees() takes a callback from the caller in o->fn().  It
>    promises (but fails to keep the promise) that the callback is called
>    with entries with matching names, so that it gets to see D/F
>    conflicting entries in one go.

Indeed. I'd _like_ to do it at this level (or even at the o->fn() level), but quite frankly, unpack_trees() is so horribly complicated, and you'd have to remember state, that doing it at this level is not realy maintainable.

>  * traverse_trees() takes a callback from the caller in info->fn().  It
>    feeds the callback the entries with the same name most of the time, but
>    that is not a guarantee, and the bug we are seeing is coming from a
>    caller, unpack_trees_callback(), assuming it.

This is the level I'm looking at. In fact, I'm going to cheat. I'm not going to do it when we call info->fn(), I'm going to do it _before_ the call, and have a special "find conflicts" phase inside traverse_trees() itself.

That way, any traverse_trees() user will see the conflicts exactly like they used to, because I'm just going to add a special "find conflicts" phase there that does the right thing. It's a hack, but it's a "useful" hack, and it at least avoids being the current "it can't work for the special case" thing.

> Do you mean we would still keep the promise unpack_trees() makes to its
> callbacks, e.g. threeway_merge(), or do you mean these callbacks are to be
> prepared to get DF-split input themselves and expected to coalesce them
> as necessary?

Either would work, but changing unpack_trees() semantics would just be very painful. There are just too many users of it, and they are too ingrained in their expectations of getting conflict information in a single pass.

I think I have a good solution, give me half an hour to actually get it to work.

			Linus