{"thread":{"id":"59001","subject":"Theirs merge strategy","startedAt":"2022-12-25T17:25:04Z","lastAt":"2022-12-26T04:50:55Z","messageCount":3,"participants":["git@isandrew.com","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"469527","messageId":"5b64c7f5-59e3-f319-4efa-4624907436b6@isandrew.com","threadId":"59001","inReplyTo":null,"subject":"Theirs merge strategy","fromName":"","fromEmail":"git@isandrew.com","sentAt":"2022-12-25T17:19:10Z","receivedAt":"2022-12-25T17:25:04Z","isPatch":false,"sender":{"key":"git@isandrew.com","avatar":null},"body":"Would it be possible to revisit the decision to not have a \"theirs\" \nmerge strategy?\n\nI think there are legitimate reasons to use it, beyond the plenty of \nrope argument.\n\nOne example is you're working with a successfully written and operating \nbranch through multiple releases, but due to some external change \n(product direction, upstream changes) you decide that an approach in a \ndifferent branch is better.  You want to use the other branch, while \nkeeping the history of the successful prior releases, for all the normal \nreasons one wants to keep history.  A hard reset wouldn't help in this case.\n\nThe decision to remove it was to prevent people from having bad \nworkflows.  In reality, in lieu of theirs people use ours in reverse \nwhich is even worse.\n\nThe previous discussion I found was at \nhttps://marc.info/?l=git&m=121637513604413&w=2\n\n"},{"id":"469529","messageId":"007c01d91888$74673500$5d359f00$@nexbridge.com","threadId":"59001","inReplyTo":"5b64c7f5-59e3-f319-4efa-4624907436b6@isandrew.com","subject":"RE: Theirs merge strategy","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-12-25T17:43:47Z","receivedAt":"2022-12-25T17:49:13Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 25, 2022 12:19 PM, Andrew wrote:\n>Would it be possible to revisit the decision to not have a \"theirs\"\n>merge strategy?\n>\n>I think there are legitimate reasons to use it, beyond the plenty of rope argument.\n>\n>One example is you're working with a successfully written and operating branch\n>through multiple releases, but due to some external change (product direction,\n>upstream changes) you decide that an approach in a different branch is\n>better.  You want to use the other branch, while keeping the history of the\n>successful prior releases, for all the normal reasons one wants to keep history.  A\n>hard reset wouldn't help in this case.\n>\n>The decision to remove it was to prevent people from having bad workflows.  In\n>reality, in lieu of theirs people use ours in reverse which is even worse.\n>\n>The previous discussion I found was at\n>https://marc.info/?l=git&m=121637513604413&w=2\n\nThis use case applies more generally in some release workflows. A valid (and common in my world) workflow can have with multiple release branches, and the same pull request going to a selection of release branch. Conflicts occasionally happen in the pull request merge, but the pull request, in a high audit situation cannot be modified - conflicts are resolved later under a separate signature. The -s theirs permits the pull requests to be merged intact with no changes (as required by various audit rules).\n\n"},{"id":"469537","messageId":"d3859314-1b5f-5984-77d7-81f4e883b4e2@isandrew.com","threadId":"59001","inReplyTo":"007c01d91888$74673500$5d359f00$@nexbridge.com","subject":"Re: Theirs merge strategy","fromName":"","fromEmail":"git@isandrew.com","sentAt":"2022-12-26T04:46:44Z","receivedAt":"2022-12-26T04:50:55Z","isPatch":false,"sender":{"key":"git@isandrew.com","avatar":null},"body":"On 12/26/22 02:43, rsbecker@nexbridge.com wrote:\n> On December 25, 2022 12:19 PM, Andrew wrote:\n>> Would it be possible to revisit the decision to not have a \"theirs\"\n>> merge strategy?\n>>\n>> I think there are legitimate reasons to use it, beyond the plenty of rope argument.\n>>\n>> One example is you're working with a successfully written and operating branch\n>> through multiple releases, but due to some external change (product direction,\n>> upstream changes) you decide that an approach in a different branch is\n>> better.  You want to use the other branch, while keeping the history of the\n>> successful prior releases, for all the normal reasons one wants to keep history.  A\n>> hard reset wouldn't help in this case.\n>>\n>> The decision to remove it was to prevent people from having bad workflows.  In\n>> reality, in lieu of theirs people use ours in reverse which is even worse.\n>>\n>> The previous discussion I found was at\n>> https://marc.info/?l=git&m=121637513604413&w=2\n> This use case applies more generally in some release workflows. A valid (and common in my world) workflow can have with multiple release branches, and the same pull request going to a selection of release branch. Conflicts occasionally happen in the pull request merge, but the pull request, in a high audit situation cannot be modified - conflicts are resolved later under a separate signature. The -s theirs permits the pull requests to be merged intact with no changes (as required by various audit rules).\n>\nI agree with the above on the risk of code leakage, that's why I use \nours/theirs.\n\nAnd just to get preliminary discussion out of the way, I found another \ndiscussion at https://marc.info/?l=git&m=150635053217381&w=2 .\n\nThe argument is made that using -s ours in reverse is actually a good \nworkflow, when what you wanted was -s theirs.  I believe this is wrong \non two points.\n\n1. If you have two branches, branch-a implementing process A and \nbranch-b implementing process B, simply dropping work on branch-a in \nfavor of branch-b with an \"ours\" commit to indicate the end of branch-a \nmay be fine.  However, if you have branches of differing significance, \n(say) master implementing process A and branch-b implementing process B, \na \"-s ours\" merge wouldn't touch master so you would have failed your \ninitial goal (make master tree equal branch-b tree).\n\n2. Let's say you go through the acrobatics of swapping branch names \nafter \"merge -s ours\" in commit \"c\".  The history of the new master \nwould then indicate that you were implementing process B up until \"c\", \nand after that you were implementing process A, but that's _doubly_ \nincorrect.  You were implementing process A up until \"c\", and after the \nmerge there was _no_ change.\n\nDefinitionally, a merge \"incorporates changes from the named commits \ninto the current branch\".  A normal merge does this.  A -s theirs merge \nwould do this.  A -s ours merge _doesn't_ do this, which is \ncounterintuitive, unobvious (you wouldn't know this unless you inspect \nthe merge commit itself), and consequently when it appears in the \nhistory it's hugely confusing. I would actually argue that, of the two, \nours is the strategy that shouldn't exist.\n\nIn any case, using -s ours there's no way to view a history showing \ndoing process A until a merge, then doing process B after, using normal \nconventions.\n\nIt's not my intention to convince anyone that they should incorporate \n\"-s theirs\" into their workflow, or even that \"-s theirs\" is good, just \nthat other people do have decent reasons for wanting this and to ask you \nto consider reinstating the theirs strategy.\n\n"}]}