Re: [PATCH 3/3] checkout -m: attempt merge when deletion of path was staged

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 13, 2014, 17:48 UTC
Message-ID: <xmqqzjf82sc7.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140813000317.GG24621@google.com>

Jonathan Nieder <jrnieder@gmail.com> 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.