Re: cherry-pick generates bogus conflicts on removed files

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2013, 21:14 UTC
Message-ID: <xmqqiowvy4zb.fsf@gitster.dls.corp.google.com>
In-Reply-To: <52604166.8000501@ubuntu.com>

Phillip Susi <psusi@ubuntu.com> writes:

> I have a commit I am trying to cherry pick that removes a number of
> files.  It seems to generate conflicts for those files that have been
> modified on this branch since the common ancestor.

Correct.

Without inspecting them, you would not know what you would be losing by blindly resolving to removal, hence we do not auto-resolve "one side removed, the other side changed" to a removal.

That does not need to mean that we should not make it easier for the user to say "resolve these 'one side removed, the other side changed' paths to removal".

"add -u" will be a way to say "Record the changes I made to my working tree files to the index". So presumably

	rm -f those files that the other branch removed
        git add -u

would be one way to do so. Of course, you can also use "git rm" directly, i.e.

	git rm -f those files that the other branch removed