RE: Theirs merge strategy

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Dec 25, 2022, 17:43 UTC
Message-ID: <007c01d91888$74673500$5d359f00$@nexbridge.com>
In-Reply-To: <5b64c7f5-59e3-f319-4efa-4624907436b6@isandrew.com>

On December 25, 2022 12:19 PM, Andrew wrote:

Show 17 quoted lines

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