46

I run into a Git merge conflict which I have seen before.

>git pull origin dev
From https://scm.starbucks.com/roastery-milan/choreographer
 * branch            dev        -> FETCH_HEAD
CONFLICT (modify/delete): <file name omitted> deleted in HEAD and modified in 01b734b9ae8594f03f5e481b123d80e41fb54d7c. Version 01b734b9ae8594f03f5e481b123d80e41fb54d7c of <file name omitted> left in tree.
...
Automatic merge failed; fix conflicts and then commit the result.

When I look at those conflicted files, I don't see any indication of conflicts. I guess that I need to change the Git HEAD. But, how to do so?

BTW, our GitHub has some changes recently and there are more branches for staging.

Update: Thanks everyone for your inputs. Now, I know how to deal this problem.

vic
  • 2,548
  • 9
  • 44
  • 74
  • Does it actually say file name omitted or did you do that? Let's say the file name is name.html. You can go and try to remove it. git rm name.html I can't tell based on this what is going on. Also, it says you have seen this before or did you mean that you haven't seen this before? – donlaur Jan 16 '18 at 19:44
  • `git reset --hard` – M Y Jan 16 '18 at 19:50
  • Possible duplicate of [git - merge conflict when local is deleted but file exists in remote](https://stackoverflow.com/questions/4319486/git-merge-conflict-when-local-is-deleted-but-file-exists-in-remote) – IMSoP Jul 19 '19 at 09:30

5 Answers5

54

The message says that you deleted a file in your current branch and someone else modified it in the branch you are pulling. You need to decide what to do with the file.

If you want to keep the file

$ git checkout <filename>
$ git add <filename>
$ git commit

If you want to discard the file

$ git rm <filename>
$ git commit

If the file was moved, you need to copy the changes over to the new location.

Code-Apprentice
  • 81,660
  • 23
  • 145
  • 268
  • 7
    If I want to keep the file, `git checkout` not work, it shows this file is unmerged – Yitong Feng Jun 23 '21 at 07:08
  • @YitongFeng I had the same problem. I ignored the `checkout` error. I did `git add ` and then `git commit` twice. The second time worked. I don't know why since I did them back to back. – mikey Jan 04 '22 at 11:37
  • @YitongFeng This sounds like a new question. If you still need help, click the Ask a question button. You can add a link to this question in your new one to help give context. – Code-Apprentice Jan 04 '22 at 16:18
9

It looks like there was a file that you had deleted locally, but was modified remotely:

CONFLICT (modify/delete): deleted in HEAD and modified in 01b734b9ae8594f03f5e481b123d80e41fb54d7c.

This is because HEAD refers to your local environment, and 01b73 is the SHA of the tip of the branch you are merging in (via the pull).

So, Git doesn't know whether to delete the file or to keep it.

You should first verify if you want to keep the file or not. This will be either staging the file if you want to keep it (add) or removing the file (rm).

Finally, create a commit to resolve the conflict.

Jonathan.Brink
  • 23,757
  • 20
  • 73
  • 115
8

The fundamental definition of a conflict is that you touched some source line(s) that they also touched. For instance, given:

original line (in base): He said, "Hello world!"
your replacement:        He said, "Hello wonderful world!"
their replacement:       He said, "Goodbye cruel world!"

which line should Git keep, and which one should it discard, or should there be a third outcome entirely? Git does not know, so it leaves the task to you.

In this case, your ("HEAD") change was to remove every line by removing the entire file. Their change was to modify some line(s) of the file. Git doesn't know what to do: should it delete the entire file like you did? Should it keep their modified version? Or, perhaps there is some third way to deal with the problem.

It's generally easier to delete everything again than it is to reconstruct their version (although it's not really that hard either way), so Git leaves their version in the work-tree. If that's the correct answer, you can simply git add the file to tell Git: use that version. If deleting the file entirely is the correct answer, git rm the file to tell Git: delete the file entirely. If there's some third correct answer, edit the file as necessary to put in the correct contents, and git add the file to tell Git: use that version.

In any case, you have now resolved this particular file's conflict (once you have git add-ed or git rm-ed the appropriate final result). Resolve other conflicts if necessary, then finish the merge:

git commit

or (since Git version 2.12):

git merge --continue
torek
  • 448,244
  • 59
  • 642
  • 775
7

I believe this situation arises when one side of the merge tree has deleted the file, and the other has modified it.

The solution is to either:

1) Delete the file ('git rm ...') which will give you a bad-sounding message, but will correctly delete the file when committed.

2) (I believe) Add the file ('git add ...') and then commit it.

It's up to you to decide which you need based on your desired outcome.

Laereom
  • 601
  • 7
  • 12
  • Thanks! by doing "git add . " wasn't working till I removed the actual files after keeping a backup, continued rebase and then added those files again in a separate commit after successful rebase. – QauseenMZ Mar 06 '20 at 21:10
  • Thanks! I did not think to ignore the message and `git rebase --continue`. (The problem is the same with rebase or merge.) – benjifisher Jan 11 '21 at 16:45
0

If you get a modify/delete conflict when merging two branches, it means that

  • In the branch BRANCH_DELETED, the file was deleted.
  • In the branch BRANCH_MODIFIED, the file was modified.

Most answers here only explain what this means TECHNICALLY and what commands to run to either keep the file or delete it, and one even explains some underlying GIT implementation details. Another one explains what a conflict is in general, which I think is too broad and not practical. This is an attempt to give a practical and complete answer.

If a file was deleted, there can be multiple reasons for it:

  • The entire file and its contents are obsolete and no longer needed.
  • The file was moved or renamed.
  • The file was moved to a different repository.
  • The file was split into multiple files (e.g., during refactoring).
  • Any combination of the above.

This is IMPORTANT, because you need to find out if the contents of the file still exist somewhere in BRANCH_DELETED and where they are now, so you can find out if the changes made in BRANCH_MODIFIED are still relevant and, if so, where they need to go. Even if the changes cannot be literally applied to anything that still exists, you may have to make some other changes somewhere that have the same or a similar effect. This may require understanding the code you are merging and its history, and it may even require talking to other people, so you need to think outside the box of GIT commands, GIT hashes and merging (as with most conflicts). There is no GIT command that will do this for you.

To make an informed decision, you may also need SEE the modifications that were made in branch BRANCH_MODIFIED. You can do this with one of the commands:

git diff HEAD...<BRANCH_MODIFIED> -- <FILENAME>
git difftool HEAD...<BRANCH_MODIFIED> -- <FILENAME>

(See https://stackoverflow.com/a/44956845/2279059 for details)

Then you can make the technical decision whether to delete or keep the (modified) file. You can either use the commands from https://stackoverflow.com/a/48288738/2279059 or run

git mergetool <FILENAME>

and when prompted choose to keep the modified file or delete it. Don't worry if you delete it, you can still see the modifications in the other branch as described above.

Depending on why the file was deleted and what happened to its contents, you now need to do some combination of...

  • Applying (part of) the modifications to whatever other file that the modified code has moved to
  • Something completely different that is equivalent(ish) to the modifications made in BRANCH_MODIFIED and thus resolves the conflict.
  • Any of the above, but in a different repository
  • Nothing (the contents of the file, and any modifications to it, are no longer needed)

Sorry if this is obvious to a lot of people, but there is widespread misunderstanding that conflicts are a technicality that can be resolved by running the correct GIT commands, and there may be a correlation between believing this and searching for the solution on StackOverflow.

Florian Winter
  • 4,750
  • 1
  • 44
  • 69