Re: Peculiar behavior of git 1.5.6
- From
Jonathan del Strother <maillist@steelskies.com>
- Date
- Sep 4, 2008, 09:11 UTC
- Message-ID
- <57518fd10809040211q12d1f0ddk16f2d4273ee7d488@mail.gmail.com>
- In-Reply-To
- <7vljy85mwx.fsf@gitster.siamese.dyndns.org>
On Thu, Sep 4, 2008 at 9:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 42 quoted lines
> Johannes Sixt <j.sixt@viscovery.net> 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"