git rebase "deleted by us" and "deleted by them"

Suppose I am rebasing experiment branch on master and there are conflicts in files. And of course there are files deleted in both branches. So when I am resolving the conflicts, in git status I see deleted by us and deleted by them. Its very confusing. Is there any way of understanding what they mean? Who is them and who is us?

Or while rebasing is there another way to know which file was deleted by which branch? Like printing the branch name?

Reference documentation

> Note that a rebase merge works by replaying each commit from the > working branch on top of the <upstream> branch. Because of this, when > a merge conflict happens, the side reported as ours is the so-far > rebased series, starting with <upstream>, and theirs is the working > branch. In other words, the sides are swapped.

https://git-scm.com/docs/git-rebase/2.17.0 (latest: https://git-scm.com/docs/git-rebase)

Hence, files "deleted by us" are those that were deleted on the branch you are rebasing onto (the final branch), and files "deleted by them" are files that were deleted in the branch you are rebasing (the one that will be dropped).

Demonstration

$ ls
a
$ git log --oneline --graph --decorate --all
* d055cdd (HEAD -> y) Write baz in a-file
| * 487dc8c (x) Write bar in a-file
|/  
* 3fa0da5 (master) Write foo in a-file
$ git rebase x
First, rewinding head to replay your work on top of it...
Applying: Write baz in a-file
Using index info to reconstruct a base tree...
M	a
Falling back to patching base and 3-way merge...
Auto-merging a
CONFLICT (content): Merge conflict in a
error: Failed to merge in the changes.
Patch failed at 0001 Write baz in a-file
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
$ cat a
<<<<<<< HEAD
bar
=======
baz
>>>>>>> Write baz in a-file
$ git checkout --ours a
$ cat a
bar
$ git checkout --theirs a
$ cat a
baz

AFAIK there is no switch to display the specific names of the branches explicitly with the official tools. Unless I'm wrong this is just one of those things you need to learn to get through the initial confusion.

To their credit, it does make a lot of sense if you think about it.

More pedantic analysis

The text of the manual page is a little ambiguous as it could be interpreted to be relevant only when using the --merge option. This is exacerbated by a second mention of the behavior in --strategy: "Note the reversal of ours and theirs as noted above for the -m option.".

However, I believe this is not contrasting the behavior of git-rebase when --merge is used with when it isn't; rather I believe it is contrasting the behavior of git-rebase with git-merge. The MERGE STRATEGIES section is clearly ripped from the git-merge manual page, so it's somewhat easy to imagine that the author felt the need to emphasize the swap when using rebase since it's not mentioned in that section. The following sentence, to me, confirms this interpretation: "[...] git rebase replays each commit from the working branch on top of the branch using the given strategy [...]".

Although we now understand that the merge strategy should have no impact on the sides (only the choice of git-merge vs git-rebase should), I'll note --merge is implied by the default strategy regardless (making the default behavior completely non-ambiguous).

Below is a copy of SzG's answer on a similar question:

> When you merge, us refers to the branch you're merging into, as > opposed to them, the branch to be merged. > > When you rebase, us refers the upstream branch, and them is the > branch you're moving about. It's a bit counter-intuitive in case of a > rebase. > > The reason is that git uses the same merge-engine for rebase, and it's > actually cherry-picking your stuff into the upstream branch. us = > into, them = from.