Re: Moved files and merges

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

Junio C Hamano <junkio@cox.net> 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.