git: pull sometimes refuses to merge

[dmik]

I faced the following situation: I had a local copy of ​https://github.com/bitwiseworks/mozilla-os2.git with the master branch up to date, the vendor-ear branch at the previous merge (17.0.5 to 24.3.0) and the remote vendor-esr branch was already updated from 24.3.0 to 24.8.0 (on another machine).

When I switch to that branch with git checkout vendor-esr locally, git correctly says that my local copy is 1 commit behind (this commit is the update to 24.8.0) and that it can be fast forwarded (i.e. have this commit applied w/on any possible conflicts).

However, when I do git pull (that first checks that remote changes are here with fetch and then calls merge to fast-forward), it fails with the following message:

error: The following untracked working tree files would be overwritten by merge:

And then comes the list of the new files brought by the commit being fast forwarded. A subsequent git status call shows that there are no changes except these new files.

This surely didn't happen when I fast forwarded other branches with the new build of git 2.0.0 (i.e. the master branch of the mozilla repo or my test repo I created for playing with git).

[dmik]

Strange enough that doing git pull from my Mac (where I have git 1.8.5.2) over Samba (where git is guaranteed to be fine), I get exactly the same. This may mean two things:

1. My repo on OS/2 is somehow broken.
2. There is a cross-platform (and long standing) bug in git itself.

1 is much more likely. I did some things not right before coming to that stage. So may be I screwed it up. Partly this is confirmed by the fact that after a clean clone all worked. But that was not exactly the same situation as in this case all new changes were already there and checking out vendor-esr just took all the current remote changes.

Anyway, I will watch this problem and leave the ticket open for the time being.

[dmik]

I can't reproduce this problem with the fresh git 2.11.0 build so far. They made the pull command a builtin rewritten in C (instead of shell script), may be this improved the situation. Anyway, before I close it I need to get a similar condition (i.e. have my local repo get behind the remote) and fully retest it before closing.

[dmik]

No problems in new clones created by git 2.11.0 so far. Closing this (will reopen if the problem pops up again).