Jonathan Nieder <> writes:

> twoway_merge() is missing an o->gently check in the case where a file
> that needs to be modified is missing from the index but present in the
> old and new trees.  As a result, in this case 'git checkout -m' errors
> out instead of trying to perform a merge.

I see two hunks in threeway_merge(), so two existing callers there
will not change their behaviour.  Two hunks in twoway_merge() means
that among three existing callers in that function, this one at the
end (not shown in your patch) changes its behaviour:

        else if (newtree) {
                if (oldtree && !o->initial_checkout) {
                         * deletion of the path was staged;
                        if (same(oldtree, newtree))
                                return 1;
                        return reject_merge(oldtree, o);
                return merged_entry(newtree, current, o);
        return deleted_entry(oldtree, current, o);

> This is the most iffy of the three patches, mostly because I was too
> lazy to write a test.

You would trigger this codepath by jumping from an old revision to a
new revision after "git rm $path" any path that has been modified
between the two.  The only behaviour difference is that it will stop
issuing an error message---the "checkout -m" will successfully switch
between the revs and leave the index in a "we modified, they removed"
conflicting state with or without your patch.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to