* Re: Theirs merge strategy
2022-12-25 17:43 ` rsbecker
@ 2022-12-26 4:46 ` git
0 siblings, 0 replies; 3+ messages in thread
From: git @ 2022-12-26 4:46 UTC (permalink / raw)
To: rsbecker, 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.
^ permalink raw reply [flat|nested] 3+ messages in thread