On Sun, 6 Sep 2009, Junio C Hamano wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html