git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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"

Previous: Junio C HamanoNext: Junio C Hamano
Message 4 of 7 in “Peculiar behavior of git 1.5.6”
  1. Larry FingerSep 4, 2008
  2. Johannes SixtSep 4, 2008
  3. Junio C HamanoSep 4, 2008
  4. Jonathan del StrotherSep 4, 2008
  5. Re*: Peculiar behavior of git 1.5.6Junio C Hamano, Sep 4, 2008
  6. Nanako ShiraishiSep 4, 2008
  7. Larry FingerSep 4, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.