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).