On December 25, 2022 12:19 PM, Andrew wrote: >Would it be possible to revisit the decision to not have a "theirs" >merge strategy? > >I think there are legitimate reasons to use it, beyond the plenty of rope argument. > >One example is you're working with a successfully written and operating branch >through multiple releases, but due to some external change (product direction, >upstream changes) you decide that an approach in a different branch is >better. You want to use the other branch, while keeping the history of the >successful prior releases, for all the normal reasons one wants to keep history. A >hard reset wouldn't help in this case. > >The decision to remove it was to prevent people from having bad workflows. In >reality, in lieu of theirs people use ours in reverse which is even worse. > >The previous discussion I found was at >https://marc.info/?l=git&m=121637513604413&w=2 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).
