Re: Theirs merge strategy

[git@isandrew.com]

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.