Re: Multi-ancestor read-tree notes

Daniel Barkalow <barkalow@iabervon.org> writes:

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.