Re: cherry-pick generates bogus conflicts on removed files

[Junio C Hamano <gitster@pobox.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