如何在git pull上暂时忽略未跟踪的文件？

Question

I have some new files that I didn't add to git yet; I'm not sure I will, I'm still undecided. But I want to get whatever is latest in the server.

However, when I do a git pull I get the error error: Your local changes to 'XXXX' would be overwritten by merge. Aborting. error: Your local changes to 'XXXX' would be overwritten by merge. Aborting. , where XXXX is my new file.

How can I tell git to download the changes and new files from the server, tell me about possible conflicts between what's on the server and my local modifications to files already in the repository, while at the same time not aborting because I have new files locally?

I don't want to add them to .gitignore, as I have this situation frequently and I don't want to be adding and removing files from .gitignore all the time for silly stuff... especially because I don't want to run the risk of forgetting about a certain file that in the end I would decide that it has to be added to the repository, so I want git status to keep telling me about them. Sometimes I run git status -uno when I want to ignore new files, and then sometimes I run git status to see what's new and decide what to keep and what to discard. But I couldn't find an equivalent option for git pull .

My attempts at googling take me to people who want to overwrite their local changes with what's on the repository, or other similar scenarios. :( After reading the documentation I found that I can do a git fetch to bring my local repository up to date, that didn't yield any errors, but it also didn't bring the changes to my working copy. I can't figure out the next step after that. :-/ In any case, a pull with no errors would be ideal...

Answer 1

You will have to either stash it first and apply the changes after you have pulled from the remote or reset the current branch to the last commit. Resetting the branch will cause you to lose your changes.

git stash

// after you have pulled from remote
git stash apply 
// OR
git stash pop

A very good explanation on the difference between apply and pop can be found here

---

You can also choose to reset your current branch with the following command.

git reset --hard

Answer 2

As you probably know, git pull is basically git fetch followed by git merge .

The step that is failing is not the git fetch , it's the git merge :

 ... overwritten by merge 

Note the last word here is merge . What this means is that your undecided-ness:

I have some new files that I didn't add to git yet; I'm not sure I will, I'm still undecided.

has already been decided for you , by someone else, at least for one such file: that particular file is added now, in that other commit. That's the one that Git will overwrite.

You now have a choice of various options:

• Don't merge (or don't merge yet): you can leave the file untracked. I think this is pretty clear, but it leaves the situation unresolved. Eventually you'll (probably?) have to merge....

• Do merge: the file will become tracked. You then have sub-choices about how Git should deal with your existing untracked file:

  • Add and commit. Git will merge your change-since-the-base with their change-since-the-base. Presumably both changes are add this file , ie, the file is not in the merge base. This means the conflict will be an add/add conflict , which is kind of a pain.
  • Save your version of the file elsewhere, removing the untracked one. Let Git merge (as fast-forward or real merge, whichever it does). Manually merge in your own changes, add, and make your own new commit.
  • The other guy is wrong, and the file should not be tracked: Save your version of the file elsewhere. Let Git merge. Remove the file and commit, committing the removal. You can then put your own untracked file back.

There are some additional options (such as rebasing instead of merging) but they all wind up with the same situation: either the file is tracked (as it is in the commit you told Git to merge), or you must update to that commit anyway, remove the file, and commit again to make a commit in which the file won't be tracked.

The way you "save the file elsewhere" is up to you: for instance, you can just move it out of the work-tree entirely, or you can use git stash to make a commit that has the file.

When it works, git stash is pretty convenient, but because it actually makes two or three commits that are not on any branch, it is quite a complicated little beast, and when it goes wrong it becomes very difficult to deal with. So for anything that itself might be complicated, I like to avoid git stash . Note that git stash by default stashes only tracked files, so you must git add it to get it into the two commits that git stash normally makes. You can use git stash -u to specifically make a third commit that holds the untracked files, but this makes the stash harder to deal with.