Re: Handling merge conflicts a bit more gracefully..

LT> I think that sounds reasonable. Is it not the case now?

Well, except that $I may validly be an empty tree ;-), so not quite.

In case it was not clear, where I am headed is this. I would like to rip out the two-tree "carry forward" implementation from read-tree, and replace it with:

    read_cache() -- current goes to stage0
    read_tree(H) -- H goes to stage1
    read_tree(M) -- M goes to stage3
    for each path
        if it appears in stage0, copy it to stage2
        else if it appears in stage1, copy it to stage2
    threeway_merge() !!

And then the resulting possibly unmerged cache can be resolved exactly the same way with merge-cache.

The trouble I feel with the current "carry forward" code is that when it works it does sensible thing, but otherwise does not help the end user at all. With all the work going into making merge-one-file-script nicer today, I think leveraging three-way merge support for two-tree fast forward case would make a lot more sense than keeping the all-or-nothing carry forward code I recently added to it.

When/if that happens, then the current fast-forward code would need to be changed from:

    read-tree -m $H $M && echo $M >.git/HEAD

to

    read-tree -m $H $M &&
    if unmerged paths in the resulting cache
    then
        merge-cache -o merge-one-file-script -a
    fi &&
    echo $M >.git/HEAD

and the user's local changes since H when fast forwarding to M would be handled with the same workflow as the three-way case.

Hmm.