Keep 'ours' and 'theirs' seem to be inverted.

[e-dard]

I have the following key bindings setup:

[
  { "keys": ["ctrl+alt+f"], "command": "find_next_conflict" },
  { "keys": ["ctrl+alt+o"], "command": "keep", "args": { "keep": "ours" } },
  { "keys": ["ctrl+alt+t"], "command": "keep", "args": { "keep": "theirs" } },
  { "keys": ["ctrl+alt+a"], "command": "keep", "args": { "keep": "ancestor" } },
  { "keys": ["ctrl+alt+c"], "command": "list_conflict_files" }
]

When I have a conflict, e.g.,

<<<<<<< HEAD
### Foo
=======
- item
>>>>>>> my branch commit message

and I hit ctrl+alt+o I expect my change to be kept, but instead it's resolved to:

### Foo

And the inverse happens when I hit ctrl+alt+t. Looks like the commands are the wrong way around?

[sascha-wolf]

ours is always the leading block, while theirs is always the trailing one.

Your confusion could stem from the fact that ours and theirs might appear swapped during a rebase. Quote from the git documentation (emphasis mine):

Note that during git rebase and git pull --rebase, ours and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while --theirs gives the version from the branch that holds your work that is being rebased.

This is because rebase is used in a workflow that treats the history at the remote as the shared canonical one, and treats the work done on the branch you are rebasing as the third-party work to be integrated, and you are temporarily assuming the role of the keeper of the canonical history during the rebase. As the keeper of the canonical history, you need to view the history from the remote as ours (i.e. "our shared canonical history"), while what you did on your side branch as theirs (i.e. "one contributor’s work on top of it").

[e-dard]

@Zeeker aha, yes! So the first time I tried the plugin out I happened to be doing a rebase, and I made the assumption. :+1: