Phillip Susi <psusi@xxxxxxxxxx> 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
--
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