Git pull -X theirs doesn't work

Question

I get the following errors when I pull:

error: The following untracked working tree files would be overwritten by merge: [list of files]. Please move or remove them before you can merge.

Your local changes to the following files would be overwritten by merge: [list of files]. Please, commit your changes or stash them before you can merge.

I want to accept theirs changes for all of the listed files. However, I don't want to remove any other files! I don't want to commit them either. There are a lot of files and I don't want to deal with them individually.

I found the following answers, which look perfect and used them:

a) git pull -X theirs
b) git pull --strategy-option theirs
c) git fetch
   git merge -X theirs
d) git fetch
   git pull --strategy-option theirs

But I get the same error. What is going wrong? I use git 2.7.

Answer 1

Your (a), (b), and (c) methods all do the same thing. Remember, git pull is just git fetch followed by git merge. Moreover, -X and --strategy-option are just alternative spellings for the same option. Your method (d) merely runs two git fetch commands in a row followed by one git merge.

---

Both complaints you show are about a file named files. However, they are different complaints, which means you have done something to the actual error messages. I'll address both cases anyway:

1. Untracked files are generally un-merge-able. Usually the file must be in all three commits: the merge base commit, and both branch tip commits. (There are some cases where a deliberately removed file can be merged, though many of those cases result in delete/modify conflicts, which Git cannot resolve on its own. I doubt you have one of these cases though.)

2. Uncommitted changes (to tracked files) are difficult (and inadvisable) to merge.

For case 1: It's not clear why the file named files is untracked in your tip commit, but is present in their tip commit. You could git add this file and git commit the result, but if the file is not present in the merge base, you would then get an "add/add conflict" on this file, and still need to resolve it manually.

It's not possible to tell (from the information you provided) whether this file is in the merge base, but chances are that it is not. The most likely way for it to be in the merge base, missing from your current commit, and present in their tip-most commit, would be if you had explicitly removed it (with git rm) and committed this result, and if you had done that, you would not be asking about this now.

Your best bet is probably to move your file named files out of the way. You can then run the two git fetch and git merge commands (perhaps by running the one git pull command as you are trying to do—I usually advise breaking this into its two separate components because when things go wrong, you need to take different actions to resolve the problem, depending on which one failed, but it's rare for the "fetch" step to fail). Once the merge is done, you can then decide whether you prefer their files file, or your original files file, or some mix of the two, and construct the desired final files file by hand.

For case 2: you have modified the file named files, which is present in your tip commit, and is also present in their tip commit. You have not yet done git add files and git commit. It is strongly advised that you commit this change before attempting to merge. You cannot use git merge to merge their tip commit with your tip commit until you commit the file. (It is possible to attempt the merge anyway, but not with git merge, not since Git version 1.5.0.2. But don't do that.)

I want to accept theirs changes for all of the listed files. However, I don't want to remove any other files! I don't want to commit them either. There are a lot of files and I don't want to deal with them individually.

You only showed one file, named files. If you have made substantial changes to the actual output, all of the above may be useless advice: we can only respond to what you actually tell us. Nonetheless, your best bet is probably going to be to commit these files.

You should never be afraid to make commits. If you do not want those commits to be done on the current branch, make a new branch, then make the commit (git add the files and git commit the result). The new commit on the new branch will be separate from all other commits on any previous branches, and you can switch back to previous branches or previous commits at any time. You can then choose when to merge their work with your work, and when (and whether) to use exclusively their work, or your work.

Note that you will still get add/add conflicts on files you added that they also added, once you actually do get around to merging. If you simply want to use their version of such files, that's easy to do, even more or less automatically. (If you want a smarter merge that uses the common portions of both of your work as a merge base, that's more difficult, although newer versions of Git seem to be growing this ability.)