Jonathan Nieder <jrnieder@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html