Re: Multi-ancestor read-tree notes

[Junio C Hamano <junkio@cox.net>]

Daniel Barkalow <barkalow@iabervon.org> writes:

> In case #16, I'm not sure what I should produce. I think the best thing 
> might be to not leave anything in stage 1. The desired end effect is that 
> the user is given a file with a section like:
>
>   {
>     *t = NULL;
>     *m = 0;
> <<<<<<<<
>     return Z_DATA_ERROR;
> ========
>     return Z_OK;
>>>>>>>>>
>   }

I was thinking a bit more about this.  Let's rephrase case #16.
I'll call merge bases O1, O2,... and merge heads A and B, and we
are interested in one path.

If O1 and O2, the path has quite different contents.  A has the
same contents as O1 and B has the same contents as O2.  We
should not just pick one or the other and do two-file merge
between the version in A and B (we could prototype by massaging
'diff A B' output to produce what is common between A and B and
run (RCS) merge of A and B pretending that the common contents
is the original to produce something like the above).

If A has slight changes since O1 but B did not change since O2,
ideally I think we would want the same thing to happen.  Let's
call it case #16+.

What does the current implementation do?  It is not case #16
because A and O1 does not exactly match.  I suspect the result
will be skewed because B has an exact match with O2.  The
situation becomes more interesting if both A and B has slight
changes since O1 and O2 respectively.  They do not exactly match
with their bases, but I think ideally we would like something
very similar to case #16 resolution to happen.

One way to solve this would be to try doing things entirely in
read-tree by doing not just exact matches but also checking the
amount of changes -- if each heads has similar but different
base call it case #16 and try two-file merge between the heads
disregarding the bases.

But I am a bit reluctant to suggest this.  My gut feeling tells
me that these 'interesting' cases are easier if scripted outside
read-tree machinery to later enhance and improve the heuristics.

Of course, the current case #16 detected by the exact match rule
should be something we can automatically handle, but to make
things safer to use I think we should have a way to detect case
#16+ situlation and avoid mistakenly favoring A over B (or vice
versa) only because one has slight modification while the other
does not.