cherry-pick generates bogus conflicts on removed files

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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. Since they are being removed, I don't care about what changes have been made on this branch, just remove them. Even git cherry-pick -Xtheirs does not help. How can I avoid these conflicts, or accept the deletions? I tried git add -u, but that seems to take my version rather than accept the deletion, and there is no -u switch to git rm.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSYEFlAAoJEJrBOlT6nu75kSEIAMjqXl6nhfEhIMC66Zh4W/y0 MZ/+acDUNdvpCDtEpf9nPIFBQUKxdqAhUg0qYLSOvdvhQIvxkgo6nMo15MAA5Dd/ jNPZD78m0qwvNooUhFiHdqSEwob+2ntA9/VVP+LgCsRcK6BUqHs1Z3MKbe4vXPYr +/bs11daxcnHH81aXOwRcOlUZRsG+yCDQiD9qjhPyv0BCCdS9splC+R7JZy4VaYb 6GQ03G7oY0yFGV9UAOXD1OqDwVPc30tinXlCM2GaBQNc11IQzpi813nEyxTOaf3Z P5BXXH5ZzDNQS5F6Dn/VVNM6MMxVugIgGJafd4EkJiRHw4fIcUCX3/aeDoEDHlc= =uy2D -----END PGP SIGNATURE-----

Phillip Susi <psusi@ubuntu.com> writes:

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/17/2013 5:14 PM, Junio C Hamano wrote:

Even when I specify the "theirs" strategy? It seems like saying to unconditionally accept their changes should not generate conflicts.

I have about two dozen such files. Are you saying I have to individually remove each one?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSYTbNAAoJEJrBOlT6nu752lAH/33YymYr773UZY8ryioA7dkQ he3qjYzxWdIY2FtNFfYER1o1Q7PpeDLvq61b67IZ2htFjiK4+xgM/q+wjp3RMkXI sA2vQ9iNn8dvR+PlzR9DgOFcDD17p3Q/xbu3H/M4Nt+H3px+Yz6sjUUSOzDAzXl8 ADQe0g4KkQnY4fjx+iWbrygY5xXCaQ52693pwYvR67GijfYxIuNb4d9DpkZhyqIZ L6qjJH4FR1AZl6n5hPj0a9ZitrO8J/MjJ24oLVBfBU2h1GF5h7LoavkU02S874BZ /8fULrCYfTCMSkyOCnk2xCkhw3sbqU9vEu90npI5X1nRbZZ0ro/DPAjXCgHB40c= =EB2w -----END PGP SIGNATURE-----

Phillip Susi <psusi@ubuntu.com> writes:

I think you are thinking about "-Xtheirs" (which is not a strategy).

There is no "theirs" strategy, IIRC, even though there is "ours" strategy (the asymmetry is pretty much deliberate), but if there were, it would tell Git to unconditionally accept their version, just like "ours" strategy does for our version.

Just in case you are unfamiliar with how the merge works, during a merge, these things happen:

 - we first merge at the tree structure level; trivial cases such as
   "one side changed, the other side kept the original" and "one
   side changed, the other side also changed but to the identical
   result" will be resolved during this phase.

 - paths that changed by one side in one way and by the other side
   in a different way are fed to the content-level merging code to
   decide the merged contents for each path.  -X<options> are given
   to this content-level merge logic.

 - other paths that do not qualify for content-level merging
   (i.e. lacking the two resulting versions) are left conflicted.

If you do not have it in "ours" side, the content-level three-way merge mechanism does not even kick in in the current code.

It might be a good idea to peek into -Xtheirs/-Xours during the tree-level merging phase and have these options help resolve the structure level merges, but I think it needs to be thought through to avoid surprises. While I tend to agree with you that when you are using "-Xtheirs" to really prefer all their changes over your changes when they overlap at the content level, you are likely to prefer ignoring your changes and take their removal of a path, I suspect that there may be those who want the preference applied only to the whole-file "I changed the path that they have already removed" without losing the ability to inspect the content level conflicts in files that both sides kept and resolve them manually, instead of blindly taking theirs, for example, and if that is the case, overloading this new behaviour about the whole-file removal to existing "-Xtheirs" may be a mistake.