Re: Handling merge conflicts a bit more gracefully..

LT> Yeah, ok, so the fact that we allow missing things in the LT> index (which was debatable to start with) makes for LT> exceptions.

Not just that. Another big difference is that we allow _extra_ things in the index in two-tree case (i.e. local additions). But I do not think these exceptions are necessarily bad.

And you are right that two-tree is _very_ different from three-way merge.

LT> We could certainly be stricter about the index contents, and LT> require that they match the branch we're merging from LT> exactly, rather than be a subset.

I guess great minds do not always think alike. I was going in quite the opposite direction. I vaguely recall saying this before on this list ;-)

With the current three-way code, if I rewrite two-way merge using the three-way "read-tree -m H I-mixed-with-H M" (emulated two-tree fast forward, where "I" denotes "tree that would have resulted from the original cache"), it would give quite different results from the "carry forward" two-way code we have. So in that sense, three-way and two-way are quite different.

I have, however, not convinced myself that this difference is coming from some fundamental difference between two-tree fast forward and three-way merge. If desirable results fall out naturally for the "emulated two-way" case by handling three-way case more carefully (e.g. not having stricter index requirements than necessary), that would be wonderful. I think, for example, there are places where we have too strict index requirements in three-way merge (grep for '(ALT)' in t/t1000*.sh test file).

I probably am dreaming, though.

LT> I think the case that is more important (and more likely to LT> hit people) is when they have something in their working LT> tree that conflicts with the merge, and then what you want LT> is really that the current "update" code do the three-way LT> merge in the working directory, not that it's done on the LT> index file contents.

LT> ..., but I don't think the index file is the most important LT> case. The more important case is the one that the three-way LT> merge doesn't handle either!

I agree with all of the above. Their working tree has changes from H, and merging M into H conflicts with those changes. That means, although they did not actually make a formal commit, what they have is essentially this:

         cache contents
         is here
         v
      ---I---
     /       ^work tree contents is here
  --H
     \
      ----------M

which means we are exactly in the same situation as "merge I and M pivoting on H" three-way merge, with a dirty work tree. Any solution and help we would give to the end-user for the three-way case would automatically help this two-way case, wouldn't it?

I do not think index file is important either; maybe I am not really understanding your argument. I fully accept the new world order with today's merge-one-file-script changes, that the merge result will be left in the work tree for the user to verify and sort out. What I am trying to do in the above picture is to help the end-user forward-porting differences in I since H (along with the work tree changes since I) when doing a fast-forward from H to M happens, using the files in the work tree.