1

Same ask as Resolve Git merge conflicts in favor of their changes during a pull

Instead, not during a pull but during rebase.

git rebase has the option of:

-s, --strategy <strategy>
                      use the given merge strategy

I tried to use the recursive "theirs" strategy option as per here:

git merge --strategy-option theirs

From the man:

ours
    This option forces conflicting hunks to be auto-resolved cleanly by 
    favoring our version. Changes from the other tree that do not 
    conflict with our side are reflected to the merge result.

    This should not be confused with the ours merge strategy, which does 
    not even look at what the other tree contains at all. It discards 
    everything the other tree did, declaring our history contains all that
    happened in it.

theirs
    This is opposite of ours.

But when I tried it, I got:

$ git rebase -s theirs master addon/btx
git: 'merge-theirs' is not a git command. See 'git --help'.

BTW,

$ git version
git version 2.30.2
xpt
  • 20,363
  • 37
  • 127
  • 216

1 Answers1

2

In git merge and git rebase, -s specifies a strategy, and --strategy-option specifies a strategy option. These are entirely different, almost like the way that a head and head cheese are entirely different.

This is highly confusing. I prefer to refer to "strategy options" like theirs as eXtended options which makes it a little clearer that if you want the single letter option, you must use -X. That is:

git merge -X theirs ...

These extended options are passed to the strategy you choose (which defaults to recursive in older Git versions and ort in modern Git, in most cases). The same goes for git rebase.

Note that -X theirs blindly chooses the #3-slot index variant when resolving in-file merges. It has no effect on high-level (file-level) conflicts and blindly choosing an index slot is fast, but not always right (although then again, the lack of a conflict isn't always right in the first place, if that occurs). Note further that slot #3 during rebase is the commit we're cherry-picking (i.e., more "ours" than "theirs" despite the name theirs). Slot #2 is the commit we're building on, which is initially "theirs", and later sort of a blend of ours-and-theirs.

torek
  • 448,244
  • 59
  • 642
  • 775
  • hmmm..., are we talking about `git rebase` here? – xpt Jul 21 '22 at 02:10
  • `git rebase` and `git merge` share the options (and the merge engine), but note that `-X theirs` during rebase still refers to slot #3, which is more "ours" than "theirs". I've updated the wording. – torek Jul 21 '22 at 04:04
  • _"git rebase and git merge share the options (and the merge engine)"_. OIC. Great. thanks! – xpt Jul 21 '22 at 16:12
  • sorry @torek I dont have another way to tag you but to do this https://stackoverflow.com/questions/72657075/git-conflict-markers-showing-a-different-file-update?noredirect=1#comment129049249_72657075 – Oxycash Jul 22 '22 at 17:13