Git merge conflict on a file I don't have?

Question

I'm pulling from a repo with commits that modify an XML file pretty substantially since I started working on it on this device. When I run a git pull, I get merge conflicts on the file but no longer want the local changes, so I just do a git reset --hard before pulling to ensure that I won't run into any conflicts. After pulling again, I still get merge conflicts - If there are no local changes, shouldn't git just do a fast-forward and update the file? If not, why was I able to push those changes without problems?

In order to try to fix this, I simply delete the local copy of the file so that a git pull will create it, but I again see merge conflicts on a file that no longer exists. How is it that I'm able to have conflicts when I don't have the file? Shouldn't it be created without problems?

Answer 1

Doing a git reset --hard (without another argument) will reset the current HEAD back to HEAD—so to itself—and also throw away all uncommitted changes in the working directory. So you end up with a clean state for all files that Git is tracking. This clean state of the working directory is actually a requirement to perform a merge (except some special cases). It however does not prevent you from getting merge conflicts.

A merge conflict happens, when the two branches being merged have conflicting file changes (not states), which Git cannot figure out on its own.

In your case, the branch you are merging in has—as you say—substantial changes to the file. Because you are getting a merge conflict, this means that you also have committed some changes to the same file, which are incompatible. So you do have local changes to the file.

You tried to fix this, by removing the local file. However, a file removal is a change to the file: It is deleting its content. So when merging, it is possible that you indented the file to be deleted, making it again not clear what the final version should be (should the file be deleted now, should the merged-in version be used, or should both be combined in some way?). So you still end up with a merge conflict, which you need to resolve.

If you don’t care about whatever you did to the file locally, you can easily resolve the merge conflict though, by just taking the remote version and keeping it as it is:

1. First, start the merge using git pull. You should get a merge conflict on that file.
2. As you don’t care about your local version, just check the remote version out using git checkout origin/master -- path/to/that/file.xml (adjust origin/master to the remote branch, and the file path too).
3. Now the file is in the exact same state as it is in the remote branch you are merging in.
4. Add the changes: git add path/to/that/file.xml
5. If required: solve other merge conflicts
6. Commit the merge to complete it.

And then you will be in a state where you successfully merged the branch in, and resolved the merge conflict by taking the remote state of that file.