git pull from clean directory has merge conflicts

I did a git pull from my upstream on a clean working directory and it presents me with merge conflicts. I spent about an hour manually resetting them thinking I had screwed something up and it happened again.

Is this a bug in git? I know little about it, so I'm fully willing to accept that I did this to myself.

Here's my truncated output (it happens to about 9 files but I wanted to save space, and file names have been changed to protect the innocent):

$ git status
# On branch master
nothing to commit (working directory clean)
$ git pull
Auto-merged xxxx/xxxx/xxxx.xxx
CONFLICT (content): Merge conflict in xxxx/xxxx/xxxx.xxx
Automatic merge failed; fix conflicts and then commit the result.

I'm using Solaris 11 Express with the package default git.

$ uname -a
SunOS xxxx 5.11 snv_151a i86pc i386 i86pc Solaris
$ git --version
git version 1.5.6.5
$ pkg list git
NAME (PUBLISHER)                     开发者_开发百科         VERSION         STATE      UFOXI
developer/versioning/git                      1.5.6.5-0.151.0.1 installed  -----

I found this question: Git pull fails: You have unstaged changes. Git status: nothing to commit (working directory clean), which seems closest but has an unsatisfying answer.

How can I get past this without deleting my entire repository and making a new clone?

Your working directory may be clean, but you have one or more commits that you have made locally that are not on the server. When you pull, git tries to merge these local commits with the ones on the server, but since they modify the same area of the code, they conflict.

Your options here basically boil down to:

1. Fix the conflicts. You tell git how to handle the conflicting changes, and move on.
2. Rebase and fix the conflicts, with git pull --rebase. This is not much different from 1, but if your changes have never been published (ie, they've never been pushed, ever), this may get you a cleaner (linear) history.
3. Discard your local changes and use the remote's, with git reset --hard remotename/remotebranch. This will lose any changes you have committed locally but not pushed elsewhere.

Pull, resolve the merge conflicts and commit? Even if you have a clean working directory, if you have committed some work, that is conflicting with the incoming changes, you get a merge conflict.

Adding to bdonlan answer, it can happen when you have some commits (on your local repository), but the remote repository is ahead (had some progress comparing to your local committed files).

I just got stuck when I could not push nor pull due to those conflicts.

Tried to do 'rebase' or 'reset --hard' with no luck.

The only solution worked for me was to go back one commit and pull;

Follow the next steps:

Warning: this is a destructive operation which will cause you losing your last changes to this code, so backup your changes first!

1. Use 'git log' on your local repository and compare this to the commits log on the remote - to understand which one of your commits was not pushed
2. Use 'git reset --hard' to go back to the last time your code fit to the remote repository (I used 'git reset --hard HEAD^' to deliberately lose my previous commit)
3. Now 'git pull' will work; use it to get the latest code from the remote server