How do I see the changes in a tree conflict ("deleted by us" or "deleted by them")?

Question

When merging or rebasing two branches in git, and a file has been deleted in one but modified in the other, git gives a conflict. git status shows the file as "deleted by us" or "deleted by them".

I've found plenty of questions talking about how to resolve the conflict, including:

• git - merge conflict when local is deleted but file exists in remote
• How do I fix a merge conflict due to removal of a file in a branch?

However, most of the answers assume you already know exactly what the conflict is, and just need to tell git to keep or delete the file.

How do you find out what changed in the version of the file that was not deleted? git simply leaves the whole file in the working copy, and doesn't mark any changes.

For instance:

• on branch develop, user A changes file foo.x
• on branch feature, user B refactors the code, deletes file foo.x because its functionality is now in other files
• user B tries to merge develop into feature, and gets a conflict marked deleted by us
• how does user B see what user A changed, to see if the changes are needed in the refactored code?

Answer 1

If "deleted by us":

git diff <your-branch>...<branch-you're-merging-to> /path/to/file

If "deleted by them":

git diff <branch-you're-merging-to>...<your-branch> /path/to/file

From the git-diff man page:

git diff [<options>] <commit>...<commit> [--] [<path>...]

This form is to view the changes on the branch containing and up to the second <commit>, starting at a common ancestor of both <commit>. "git diff A...B" is equivalent to "git diff $(git merge-base A B) B". You can omit any one of <commit>, which has the same effect as using HEAD instead.

This will only show you the changes made in the branch that didn't delete the file i.e. if the branch that deleted the file made any changes to it first those won't be reflected in the diff.

If you're rebasing rather than merging then the "deleted by us" / "deleted by them" messages will be the other way round so use the other command.

Answer 2

There's a slightly more obscure way to accomplish this, without needing to know any of the branch names or commits involved in the conflict. You can use the notation for "index stages".

"Stage 0" is where an unconflicted file goes in the index; stages 1-3 are used for conflicts. :1:<path> means the merge base version of the file at <path>. And :2:<path> and :3:<path> refer to the two sides (I always forget which way.) So e.g. if the file in question is src/README, you can do:

git diff :1:src/README :2:src/README

git diff :1:src/README :3:src/README

And this will always show you each side of the conflict. (If one of the sides is a deletion, one of the commands will fail.)