merge-recursive: leave unmerged entries in the index.
commit28e77a81647584bfbe112f19e12e9952ab0b2fab
authorJunio C Hamano <junkio@cox.net>
Sun, 11 Dec 2005 06:05:01 +0000 (10 22:05 -0800)
committerJunio C Hamano <junkio@cox.net>
Sun, 11 Dec 2005 09:47:15 +0000 (11 01:47 -0800)
tree28aa147dac290ddb52840277fc4f42a597585125
parent7564577a6c05a1153ddb94cbe68e75c391b52f20
merge-recursive: leave unmerged entries in the index.

This does two things.

 - When one branch renamed and the other branch did not, the
   resulting half-merged file in the working tree used to swap
   branches around and showed as if renaming side was "ours".
   This was confusing and inconsistent (even though the conflict
   markers were marked with branch names, it was not a good
   enough excuse).  This changes the order of arguments to
   mergeFile in such a case to make sure we always see "our"
   change between <<< and ===, and "their" change between ===
   and >>>.

 - When both branches renamed to the same path, and when one
   branch renamed and the other branch did not, we attempt
   mergeFile.  When this automerge conflicted, we used to
   collapse the index.  Now we use update-index --index-info
   to inject higher stage entries to leave the index in unmerged
   state for these two cases.

What this still does _not_ do is to inject unmerged state into
the index when the structural changes conflict.  I have not
thought things through what to do in each case yet, but the
cases this commit cover are the most common ones, so this would
be a good start.

Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge-recursive.py