On Thu, Sep 4, 2008 at 9:35 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > >> Larry Finger schrieb: >>> On one of my systems, I found strange behavior for git-1.5.6.GIT. On the >>> first pull of the linux-2.6 tree, I got a message that one file was not >>> uptodate. When I investigated any possible differences with git-diff, >>> there were none. A subsequent git-pull worked fine. I lost the console >>> output for linux-2.6, but the same thing happened for Linville's >>> wireless-testing, as shown below: >>> >>> finger@sonylap:~/wireless-testing> git --version >>> git version 1.5.6.GIT >>> finger@sonylap:~/wireless-testing> git pull >>> error: Entry 'drivers/bluetooth/bt3c_cs.c' not uptodate. Cannot merge. >>> fatal: merging of trees 294e21019bac11cb782e8d1893d02ce98ed816a4 and >>> 810d24221c9c532475af90d1b7ba9ca381dc3696 failed >>> Merge with strategy recursive failed. >>> finger@sonylap:~/wireless-testing> git diff > tmp >>> finger@sonylap:~/wireless-testing> cat tmp >>> finger@sonylap:~/wireless-testing> git pull >>> Removed Documentation/usb/auerswald.txt >>> Auto-merged MAINTAINERS >>> ... >>> >>> Is this a bug in git, an incompatibility between my version and that of >>> the server at kernel.org, or something else? >> >> I guess you had touched the timestamp of drivers/bluetooth/bt3c_cs.c in >> some way without modifying its contents, which made 'git pull' think it is >> modified. >> >> The 'git diff' that you did next corrected this behind your back, so that >> the subsequent 'git pull' did not see any modification anymore. (BTW, if >> you had used 'git status' instead of 'git diff' you would have observed >> the same behavior.) > > That still does not explain the symptom --- shouldn't "git pull" or > underlying "git merge" have first refreshed the index? > > 1.5.6 is before the C rewrite of git-merge, so it is somewhat surprising > that if there were such bugs, but 1.5.6.GIT does not tell us much... > Incidentally - git stash pop/apply has the same problem. Touching a file, then applying the stash over the top will tell you "Cannot restore on top of a dirty state", but will work fine after a "git status" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
