Re: Peculiar behavior of git 1.5.6

["Jonathan del Strother" <maillist@steelskies.com>]

On Thu, Sep 4, 2008 at 9:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 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"