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
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