Daniel Barkalow <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
