{"thread":{"id":"35159","subject":"cherry-pick generates bogus conflicts on removed files","startedAt":"2013-10-17T19:58:30Z","lastAt":"2013-10-22T17:01:39Z","messageCount":4,"participants":["Phillip Susi","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229135","messageId":"52604166.8000501@ubuntu.com","threadId":"35159","inReplyTo":null,"subject":"cherry-pick generates bogus conflicts on removed files","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2013-10-17T19:58:30Z","receivedAt":"2013-10-17T19:58:30Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nI have a commit I am trying to cherry pick that removes a number of\nfiles. It seems to generate conflicts for those files that have been\nmodified on this branch since the common ancestor. Since they are\nbeing removed, I don't care about what changes have been made on this\nbranch, just remove them. Even git cherry-pick -Xtheirs does not\nhelp. How can I avoid these conflicts, or accept the deletions? I\ntried git add -u, but that seems to take my version rather than accept\nthe deletion, and there is no -u switch to git rm.\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.17 (MingW32)\nComment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n\niQEcBAEBAgAGBQJSYEFlAAoJEJrBOlT6nu75kSEIAMjqXl6nhfEhIMC66Zh4W/y0\nMZ/+acDUNdvpCDtEpf9nPIFBQUKxdqAhUg0qYLSOvdvhQIvxkgo6nMo15MAA5Dd/\njNPZD78m0qwvNooUhFiHdqSEwob+2ntA9/VVP+LgCsRcK6BUqHs1Z3MKbe4vXPYr\n+/bs11daxcnHH81aXOwRcOlUZRsG+yCDQiD9qjhPyv0BCCdS9splC+R7JZy4VaYb\n6GQ03G7oY0yFGV9UAOXD1OqDwVPc30tinXlCM2GaBQNc11IQzpi813nEyxTOaf3Z\nP5BXXH5ZzDNQS5F6Dn/VVNM6MMxVugIgGJafd4EkJiRHw4fIcUCX3/aeDoEDHlc=\n=uy2D\n-----END PGP SIGNATURE-----\n"},{"id":"229143","messageId":"xmqqiowvy4zb.fsf@gitster.dls.corp.google.com","threadId":"35159","inReplyTo":"52604166.8000501@ubuntu.com","subject":"Re: cherry-pick generates bogus conflicts on removed files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-17T21:14:48Z","receivedAt":"2013-10-17T21:14:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Susi writes:\n\n> I have a commit I am trying to cherry pick that removes a number of\n> files. It seems to generate conflicts for those files that have been\n> modified on this branch since the common ancestor.\n\nCorrect.\n\nWithout inspecting them, you would not know what you would be losing\nby blindly resolving to removal, hence we do not auto-resolve \"one\nside removed, the other side changed\" to a removal.\n\nThat does not need to mean that we should not make it easier for the\nuser to say \"resolve these 'one side removed, the other side\nchanged' paths to removal\".\n\n\"add -u\" will be a way to say \"Record the changes I made to my\nworking tree files to the index\". So presumably\n\n\trm -f those files that the other branch removed\n git add -u\n\nwould be one way to do so. Of course, you can also use \"git rm\"\ndirectly, i.e.\n\n\tgit rm -f those files that the other branch removed\n"},{"id":"229169","messageId":"526136CD.6080903@ubuntu.com","threadId":"35159","inReplyTo":"xmqqiowvy4zb.fsf@gitster.dls.corp.google.com","subject":"Re: cherry-pick generates bogus conflicts on removed files","fromName":"Phillip Susi","fromEmail":"psusi@ubuntu.com","sentAt":"2013-10-18T13:25:33Z","receivedAt":"2013-10-18T13:25:33Z","isPatch":false,"sender":{"key":"psusi@ubuntu.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn 10/17/2013 5:14 PM, Junio C Hamano wrote:\n> Correct.\n> \n> Without inspecting them, you would not know what you would be\n> losing by blindly resolving to removal, hence we do not\n> auto-resolve \"one side removed, the other side changed\" to a\n> removal.\n\nEven when I specify the \"theirs\" strategy? It seems like saying to\nunconditionally accept their changes should not generate conflicts.\n\n> That does not need to mean that we should not make it easier for\n> the user to say \"resolve these 'one side removed, the other side \n> changed' paths to removal\".\n> \n> \"add -u\" will be a way to say \"Record the changes I made to my \n> working tree files to the index\". So presumably\n> \n> rm -f those files that the other branch removed git add -u\n> \n> would be one way to do so. Of course, you can also use \"git rm\" \n> directly, i.e.\n> \n> git rm -f those files that the other branch removed\n\nI have about two dozen such files. Are you saying I have to\nindividually remove each one?\n\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.17 (MingW32)\nComment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n\niQEcBAEBAgAGBQJSYTbNAAoJEJrBOlT6nu752lAH/33YymYr773UZY8ryioA7dkQ\nhe3qjYzxWdIY2FtNFfYER1o1Q7PpeDLvq61b67IZ2htFjiK4+xgM/q+wjp3RMkXI\nsA2vQ9iNn8dvR+PlzR9DgOFcDD17p3Q/xbu3H/M4Nt+H3px+Yz6sjUUSOzDAzXl8\nADQe0g4KkQnY4fjx+iWbrygY5xXCaQ52693pwYvR67GijfYxIuNb4d9DpkZhyqIZ\nL6qjJH4FR1AZl6n5hPj0a9ZitrO8J/MjJ24oLVBfBU2h1GF5h7LoavkU02S874BZ\n/8fULrCYfTCMSkyOCnk2xCkhw3sbqU9vEu90npI5X1nRbZZ0ro/DPAjXCgHB40c=\n=EB2w\n-----END PGP SIGNATURE-----\n"},{"id":"229294","messageId":"xmqq7gd5utn0.fsf@gitster.dls.corp.google.com","threadId":"35159","inReplyTo":"526136CD.6080903@ubuntu.com","subject":"Re: cherry-pick generates bogus conflicts on removed files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-22T17:01:39Z","receivedAt":"2013-10-22T17:01:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Susi writes:\n\n> On 10/17/2013 5:14 PM, Junio C Hamano wrote:\n>> Correct.\n>> \n>> Without inspecting them, you would not know what you would be\n>> losing by blindly resolving to removal, hence we do not\n>> auto-resolve \"one side removed, the other side changed\" to a\n>> removal.\n>\n> Even when I specify the \"theirs\" strategy? It seems like saying to\n> unconditionally accept their changes should not generate conflicts.\n\nI think you are thinking about \"-Xtheirs\" (which is not a strategy).\n\nThere is no \"theirs\" strategy, IIRC, even though there is \"ours\"\nstrategy (the asymmetry is pretty much deliberate), but if there\nwere, it would tell Git to unconditionally accept their version,\njust like \"ours\" strategy does for our version.\n\nJust in case you are unfamiliar with how the merge works, during a\nmerge, these things happen:\n\n - we first merge at the tree structure level; trivial cases such as\n \"one side changed, the other side kept the original\" and \"one\n side changed, the other side also changed but to the identical\n result\" will be resolved during this phase.\n\n - paths that changed by one side in one way and by the other side\n in a different way are fed to the content-level merging code to\n decide the merged contents for each path. -X are given\n to this content-level merge logic.\n\n - other paths that do not qualify for content-level merging\n (i.e. lacking the two resulting versions) are left conflicted.\n\nIf you do not have it in \"ours\" side, the content-level three-way\nmerge mechanism does not even kick in in the current code.\n\nIt might be a good idea to peek into -Xtheirs/-Xours during the\ntree-level merging phase and have these options help resolve the\nstructure level merges, but I think it needs to be thought through\nto avoid surprises. While I tend to agree with you that when you\nare using \"-Xtheirs\" to really prefer all their changes over your\nchanges when they overlap at the content level, you are likely to\nprefer ignoring your changes and take their removal of a path, I\nsuspect that there may be those who want the preference applied only\nto the whole-file \"I changed the path that they have already\nremoved\" without losing the ability to inspect the content level\nconflicts in files that both sides kept and resolve them manually,\ninstead of blindly taking theirs, for example, and if that is the\ncase, overloading this new behaviour about the whole-file removal to\nexisting \"-Xtheirs\" may be a mistake.\n"}]}