Junio C Hamano <[EMAIL PROTECTED]> writes: > All true. Let's redraw that simplified scenario, and see if > what I said still holds. It may be interesting to store my > previous message and this one in a file and run diff between > them.
There are a couple of things worth mentioning about the two examples (one that I resolved favoring non-rename and non-addition, and the other I resolved favoring rename and addition) I gave tonight. 1. When I said "the principles are the same", I was primarily referring to the part that detects the 'previous' merge, which of its parents is 'ours' and which is 'theirs'. Although I handwaved that part in both examples, my gut feeling is that this part is probably harder than the part that adjusts trees before merging. klibc vs klibc-kbuild case had a clear distinction between which commit is ours and which is theirs, but I am not sure if things are that black and white in real projects when a lot of criss-crossing merges are involved. 2. When adjusting trees, I treated removals and additions a bit differently, but there is no fundamental reason to do so. In the first example which had a removal, I adjusted the tree #2 and #6 by removing the path involved. In the second example which had an addition, I did not adjust the tree #2 and #6 to add that path. But you _could_ do nothing to adjust for removal; i.e. leaving K in tree #2-adjusted and #6-adjusted in the first example. Also you _could_ adjust for the addition by copying K from #3 into #2-adjusted and copying K from #5 into #6-adjusted in the second example. If you did the former, merging the resulting #6-adjusted into #5 pivoting at #2-adjusted would leave a non-trivial conflict for you to resolve by hand. #6-adjusted changes K from #2-adjusted while #5 would remove it from #2-adjusted. This would be a remove-modify conflict (case 7 in the 3-way merge case table in t/t1000-read-tree-m-3way.sh). But this is only non-trivial to git and what you want is obvious to you as the maintainer of the line of development that removed the file at #3. You removed it the last time, and you remove it this time again. I adjusted #2 and #6 to remove the path only to save you from this tedium upfront before the read-tree phase. Similarly, in the second example, if #2 and #6 are adjusted for the addition of K by copying K from #3 and #5 into them, the resulting merge would see that one line #2-adjusted to #6-adjusted changes K (whose contents is that of #3) to that of #5, while the other line #2-adjusted to #5 changes K (whose contents is again that of #3) to that of #5. Since this is both-change-identically (case 12 in the 3-way merge table), it trivially resolves to keep K from #5, and the result is the same as what you would get from my second example which did nothing about additions. - 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
