Why is git giving me a "deleted merge conflict" when both sides are deleted?

Question

I'm merging an updated version of master into my branch. In master a file has been deleted that I also deleted. Git gives me the following:

Deleted merge conflict for 'Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs':
  {local}: deleted
  {remote}: deleted
Use (m)odified or (d)eleted file, or (a)bort?

Why is this a conflict? Both sides are deleted so surely git should just delete it?

Answer 1

First, we need a quick bit of background terminology. When you run git merge xyz, Git identifies three commits:

• Your current commit: HEAD, "local", --ours, and so on. I like to call this L for Left or Local.
• The other commit: the one identified by xyz: "remote", "other", --theirs, and so on. I like to call this R for Right or Remote.
• A third commit: the first one that L and R had in common. This is the merge base commit.

Git computes a diff from the merge base to L, and a second diff from the merge base to R. The two diffs can make different changes to files that existed in the merge base.

If Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs was a file in the merge base commit and is deleted in both heads, there will be no conflict, and this would not occur.

However, if Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs existed in the merge base and was renamed (and maybe also modified) in one commit but deleted in the other commit, there will be a rename/delete conflict. In this case, git mergetool will not find Lib/SharedBL/WebServices/WebAPI/Admin/Admin.cs in either L or R.

That particular file will, in other words, be deleted in the work-tree. But ... should it be? Should you restore the file from the base commit? The git mergetool script doesn't know. It presents you with this question.

Note that if you restore the file from the base commit, you'll still have the renamed file as well. It's up to you to figure out what to do about this.