5

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?

Jez
  • 27,951
  • 32
  • 136
  • 233

1 Answers1

4

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.

Brian Reichle
  • 2,798
  • 2
  • 30
  • 34
torek
  • 448,244
  • 59
  • 642
  • 775
  • 1
    But it says that both were deleted, not that one was renamed. And in the context where both were deleted, what does the "use modified" option do? – Jez Feb 09 '18 at 17:14
  • 1
    I looked at the source (I don't use `git mergetool`) for this answer, and I don't know *why* they wrote it the way they did. If you say "use modified" it just grabs the base version, which seems just plain wrong. There *is* a more general issue with rename/delete conflicts: the trace they leave in the index is ambiguous. The `git mergetool` shell script literally has to guess what happened. I suspect most power Git users avoid the script, which is why it has these annoying bug-ettes. – torek Feb 09 '18 at 17:37