Theirs merge strategy

Theirs merge strategy

[git]

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

RE: Theirs merge strategy

[rsbecker]

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

Re: Theirs merge strategy

[git]

On 12/26/22 02:43, rsbecker@nexbridge.com wrote:
> 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).
>
I agree with the above on the risk of code leakage, that's why I use 
ours/theirs.

And just to get preliminary discussion out of the way, I found another 
discussion at https://marc.info/?l=git&m=150635053217381&w=2 .

The argument is made that using -s ours in reverse is actually a good 
workflow, when what you wanted was -s theirs.  I believe this is wrong 
on two points.

1. If you have two branches, branch-a implementing process A and 
branch-b implementing process B, simply dropping work on branch-a in 
favor of branch-b with an "ours" commit to indicate the end of branch-a 
may be fine.  However, if you have branches of differing significance, 
(say) master implementing process A and branch-b implementing process B, 
a "-s ours" merge wouldn't touch master so you would have failed your 
initial goal (make master tree equal branch-b tree).

2. Let's say you go through the acrobatics of swapping branch names 
after "merge -s ours" in commit "c".  The history of the new master 
would then indicate that you were implementing process B up until "c", 
and after that you were implementing process A, but that's _doubly_ 
incorrect.  You were implementing process A up until "c", and after the 
merge there was _no_ change.

Definitionally, a merge "incorporates changes from the named commits 
into the current branch".  A normal merge does this.  A -s theirs merge 
would do this.  A -s ours merge _doesn't_ do this, which is 
counterintuitive, unobvious (you wouldn't know this unless you inspect 
the merge commit itself), and consequently when it appears in the 
history it's hugely confusing. I would actually argue that, of the two, 
ours is the strategy that shouldn't exist.

In any case, using -s ours there's no way to view a history showing 
doing process A until a merge, then doing process B after, using normal 
conventions.

It's not my intention to convince anyone that they should incorporate 
"-s theirs" into their workflow, or even that "-s theirs" is good, just 
that other people do have decent reasons for wanting this and to ask you 
to consider reinstating the theirs strategy.