On 12/26/22 02:43, rsbecker@xxxxxxxxxxxxx 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.
