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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 6 Sep 2009, Junio C Hamano wrote:
> 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.

> 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