iirc ours is always the commit the merge is starting from. the issue is that with a merge your current commit is the merging commit while with a rebase it is reversed.

I suspect that this could be because the rebase command is implemented as a serie of merges/cherry-picks from the target branch.

▲ Sharlin 2 hours ago | parent | next [-]

  git checkout mybranch
  git rebase main

Now git takes main and starts cloning (cherry-picking, as you said) commits from mybranch on top of it. From git's viewpoint it's working on top of main, so if a conflict occurs, main is "ours" and mybranch is "theirs". But from your viewpoint you're still on mybranch, and indeed are left on mybranch when the rebase is complete. (It's a different mybranch, of course; once the rebase is completed, git moves mybranch to point to the new (detached) HEAD.) Which makes "ours" and "theirs" exactly the opposite of what the user expects.

	▲	orthoxerox an hour ago \| parent \| next [-]
		I had to make an alias for rebasing, because I kept doing the opposite: `git checkout master #check out the branch to apply commits to git rebase mybranch #Apply all commits from mybranch` Now I just write `rebase-current-branch` and it does what I want: fetches origin/master and rebases my working branch on top of it. But "ours"/"theirs" still keeps tripping me up.
	▲	XorNot an hour ago \| parent \| prev [-]
		Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"

▲ devnotes77 2 hours ago | parent | prev [-]

[dead]