{"thread":{"id":"15368","subject":"Peculiar behavior of git 1.5.6","startedAt":"2008-09-04T05:43:55Z","lastAt":"2008-09-04T16:05:37Z","messageCount":7,"participants":["Larry Finger","Johannes Sixt","Junio C Hamano","Jonathan del Strother","Nanako Shiraishi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"89730","messageId":"48BF759B.9090309@lwfinger.net","threadId":"15368","inReplyTo":null,"subject":"Peculiar behavior of git 1.5.6","fromName":"Larry Finger","fromEmail":"larry.finger@lwfinger.net","sentAt":"2008-09-04T05:43:55Z","receivedAt":"2008-09-04T05:43:55Z","isPatch":false,"sender":{"key":"larry.finger@lwfinger.net","avatar":null},"body":"On one of my systems, I found strange behavior for git-1.5.6.GIT. On \nthe first pull of the linux-2.6 tree, I got a message that one file \nwas not uptodate. When I investigated any possible differences with \ngit-diff, there were none. A subsequent git-pull worked fine. I lost \nthe console output for linux-2.6, but the same thing happened for \nLinville's wireless-testing, as shown below:\n\nfinger@sonylap:~/wireless-testing> git --version\ngit version 1.5.6.GIT\nfinger@sonylap:~/wireless-testing> git pull\nerror: Entry 'drivers/bluetooth/bt3c_cs.c' not uptodate. Cannot merge.\nfatal: merging of trees 294e21019bac11cb782e8d1893d02ce98ed816a4 and \n810d24221c9c532475af90d1b7ba9ca381dc3696 failed\nMerge with strategy recursive failed.\nfinger@sonylap:~/wireless-testing> git diff > tmp\nfinger@sonylap:~/wireless-testing> cat tmp\nfinger@sonylap:~/wireless-testing> git pull\nRemoved Documentation/usb/auerswald.txt\nAuto-merged MAINTAINERS\n...\n\nIs this a bug in git, an incompatibility between my version and that \nof the server at kernel.org, or something else?\n\nThanks,\n\nLarry\n"},{"id":"89735","messageId":"48BF97B3.5060309@viscovery.net","threadId":"15368","inReplyTo":"48BF759B.9090309@lwfinger.net","subject":"Re: Peculiar behavior of git 1.5.6","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-09-04T08:09:23Z","receivedAt":"2008-09-04T08:09:23Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Larry Finger schrieb:\n> On one of my systems, I found strange behavior for git-1.5.6.GIT. On the\n> first pull of the linux-2.6 tree, I got a message that one file was not\n> uptodate. When I investigated any possible differences with git-diff,\n> there were none. A subsequent git-pull worked fine. I lost the console\n> output for linux-2.6, but the same thing happened for Linville's\n> wireless-testing, as shown below:\n> \n> finger@sonylap:~/wireless-testing> git --version\n> git version 1.5.6.GIT\n> finger@sonylap:~/wireless-testing> git pull\n> error: Entry 'drivers/bluetooth/bt3c_cs.c' not uptodate. Cannot merge.\n> fatal: merging of trees 294e21019bac11cb782e8d1893d02ce98ed816a4 and\n> 810d24221c9c532475af90d1b7ba9ca381dc3696 failed\n> Merge with strategy recursive failed.\n> finger@sonylap:~/wireless-testing> git diff > tmp\n> finger@sonylap:~/wireless-testing> cat tmp\n> finger@sonylap:~/wireless-testing> git pull\n> Removed Documentation/usb/auerswald.txt\n> Auto-merged MAINTAINERS\n> ...\n> \n> Is this a bug in git, an incompatibility between my version and that of\n> the server at kernel.org, or something else?\n\nI guess you had touched the timestamp of drivers/bluetooth/bt3c_cs.c in\nsome way without modifying its contents, which made 'git pull' think it is\nmodified.\n\nThe 'git diff' that you did next corrected this behind your back, so that\nthe subsequent 'git pull' did not see any modification anymore. (BTW, if\nyou had used 'git status' instead of 'git diff' you would have observed\nthe same behavior.)\n\n-- Hannes\n"},{"id":"89739","messageId":"7vljy85mwx.fsf@gitster.siamese.dyndns.org","threadId":"15368","inReplyTo":"48BF97B3.5060309@viscovery.net","subject":"Re: Peculiar behavior of git 1.5.6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-04T08:35:10Z","receivedAt":"2008-09-04T08:35:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Larry Finger schrieb:\n>> On one of my systems, I found strange behavior for git-1.5.6.GIT. On the\n>> first pull of the linux-2.6 tree, I got a message that one file was not\n>> uptodate. When I investigated any possible differences with git-diff,\n>> there were none. A subsequent git-pull worked fine. I lost the console\n>> output for linux-2.6, but the same thing happened for Linville's\n>> wireless-testing, as shown below:\n>> \n>> finger@sonylap:~/wireless-testing> git --version\n>> git version 1.5.6.GIT\n>> finger@sonylap:~/wireless-testing> git pull\n>> error: Entry 'drivers/bluetooth/bt3c_cs.c' not uptodate. Cannot merge.\n>> fatal: merging of trees 294e21019bac11cb782e8d1893d02ce98ed816a4 and\n>> 810d24221c9c532475af90d1b7ba9ca381dc3696 failed\n>> Merge with strategy recursive failed.\n>> finger@sonylap:~/wireless-testing> git diff > tmp\n>> finger@sonylap:~/wireless-testing> cat tmp\n>> finger@sonylap:~/wireless-testing> git pull\n>> Removed Documentation/usb/auerswald.txt\n>> Auto-merged MAINTAINERS\n>> ...\n>> \n>> Is this a bug in git, an incompatibility between my version and that of\n>> the server at kernel.org, or something else?\n>\n> I guess you had touched the timestamp of drivers/bluetooth/bt3c_cs.c in\n> some way without modifying its contents, which made 'git pull' think it is\n> modified.\n>\n> The 'git diff' that you did next corrected this behind your back, so that\n> the subsequent 'git pull' did not see any modification anymore. (BTW, if\n> you had used 'git status' instead of 'git diff' you would have observed\n> the same behavior.)\n\nThat still does not explain the symptom --- shouldn't \"git pull\" or\nunderlying \"git merge\" have first refreshed the index?\n\n1.5.6 is before the C rewrite of git-merge, so it is somewhat surprising\nthat if there were such bugs, but 1.5.6.GIT does not tell us much...\n"},{"id":"89742","messageId":"57518fd10809040211q12d1f0ddk16f2d4273ee7d488@mail.gmail.com","threadId":"15368","inReplyTo":"7vljy85mwx.fsf@gitster.siamese.dyndns.org","subject":"Re: Peculiar behavior of git 1.5.6","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2008-09-04T09:11:00Z","receivedAt":"2008-09-04T09:11:00Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Thu, Sep 4, 2008 at 9:35 AM, Junio C Hamano wrote:\n> Johannes Sixt writes:\n>\n>> Larry Finger schrieb:\n>>> On one of my systems, I found strange behavior for git-1.5.6.GIT. On the\n>>> first pull of the linux-2.6 tree, I got a message that one file was not\n>>> uptodate. When I investigated any possible differences with git-diff,\n>>> there were none. A subsequent git-pull worked fine. I lost the console\n>>> output for linux-2.6, but the same thing happened for Linville's\n>>> wireless-testing, as shown below:\n>>>\n>>> finger@sonylap:~/wireless-testing> git --version\n>>> git version 1.5.6.GIT\n>>> finger@sonylap:~/wireless-testing> git pull\n>>> error: Entry 'drivers/bluetooth/bt3c_cs.c' not uptodate. Cannot merge.\n>>> fatal: merging of trees 294e21019bac11cb782e8d1893d02ce98ed816a4 and\n>>> 810d24221c9c532475af90d1b7ba9ca381dc3696 failed\n>>> Merge with strategy recursive failed.\n>>> finger@sonylap:~/wireless-testing> git diff > tmp\n>>> finger@sonylap:~/wireless-testing> cat tmp\n>>> finger@sonylap:~/wireless-testing> git pull\n>>> Removed Documentation/usb/auerswald.txt\n>>> Auto-merged MAINTAINERS\n>>> ...\n>>>\n>>> Is this a bug in git, an incompatibility between my version and that of\n>>> the server at kernel.org, or something else?\n>>\n>> I guess you had touched the timestamp of drivers/bluetooth/bt3c_cs.c in\n>> some way without modifying its contents, which made 'git pull' think it is\n>> modified.\n>>\n>> The 'git diff' that you did next corrected this behind your back, so that\n>> the subsequent 'git pull' did not see any modification anymore. (BTW, if\n>> you had used 'git status' instead of 'git diff' you would have observed\n>> the same behavior.)\n>\n> That still does not explain the symptom --- shouldn't \"git pull\" or\n> underlying \"git merge\" have first refreshed the index?\n>\n> 1.5.6 is before the C rewrite of git-merge, so it is somewhat surprising\n> that if there were such bugs, but 1.5.6.GIT does not tell us much...\n>\n\nIncidentally - git stash pop/apply has the same problem. Touching a\nfile, then applying the stash over the top will tell you \"Cannot\nrestore on top of a dirty state\", but will work fine after a \"git\nstatus\"\n"},{"id":"89747","messageId":"7v3akg5jul.fsf_-_@gitster.siamese.dyndns.org","threadId":"15368","inReplyTo":"57518fd10809040211q12d1f0ddk16f2d4273ee7d488@mail.gmail.com","subject":"Re*: Peculiar behavior of git 1.5.6","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-04T09:41:22Z","receivedAt":"2008-09-04T09:41:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jonathan del Strother\" writes:\n\n> On Thu, Sep 4, 2008 at 9:35 AM, Junio C Hamano wrote:\n>> Johannes Sixt writes:\n>>\n>>> Larry Finger schrieb:\n>>>> On one of my systems, I found strange behavior for git-1.5.6.GIT. On the\n>>>> first pull of the linux-2.6 tree, I got a message that one file was not\n>>>> uptodate. When I investigated any possible differences with git-diff,\n>>>> there were none. A subsequent git-pull worked fine. I lost the console\n>>>> output for linux-2.6, but the same thing happened for Linville's\n>>>> wireless-testing, as shown below:\n>>>>\n>>>> finger@sonylap:~/wireless-testing> git --version\n>>>> git version 1.5.6.GIT\n>>>> finger@sonylap:~/wireless-testing> git pull\n>>>> error: Entry 'drivers/bluetooth/bt3c_cs.c' not uptodate. Cannot merge.\n>>>> fatal: merging of trees 294e21019bac11cb782e8d1893d02ce98ed816a4 and\n>>>> 810d24221c9c532475af90d1b7ba9ca381dc3696 failed\n>>>> Merge with strategy recursive failed.\n>>> ...\n>>> The 'git diff' that you did next corrected this behind your back, so that\n>>> the subsequent 'git pull' did not see any modification anymore. (BTW, if\n>>> you had used 'git status' instead of 'git diff' you would have observed\n>>> the same behavior.)\n>>\n>> That still does not explain the symptom --- shouldn't \"git pull\" or\n>> underlying \"git merge\" have first refreshed the index?\n>>\n>> 1.5.6 is before the C rewrite of git-merge, so it is somewhat surprising\n>> that if there were such bugs, but 1.5.6.GIT does not tell us much...\n>\n> Incidentally - git stash pop/apply has the same problem. Touching a\n> file, then applying the stash over the top will tell you \"Cannot\n> restore on top of a dirty state\", but will work fine after a \"git\n> status\"\n\nThat one is unfortunately completely an unrelated issue. \"stash apply\"\nnever refreshed the index on its own.\n\nBut pull to merge codepath in question that Larry originally brought up\nalways did, and that is what puzzles me.\n\nPerhaps some virus scanner or trackerd is running under Larry's working\ntree that contaminates the stat information after we refresh the index? I\ndunno.\n\nIn any case, I think this should fix the unrelated issue.\n\n-- >8 --\nstash: refresh the index before deciding if the work tree is dirty\n\nUnlike the case where the user does have a real change in the work tree,\nrefusing to work because of unclean stat information is not very helpful.\n\nSigned-off-by: Junio C Hamano \n---\n git-stash.sh | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git c/git-stash.sh w/git-stash.sh\nindex e15c12a..d799c76 100755\n--- c/git-stash.sh\n+++ w/git-stash.sh\n@@ -39,6 +39,7 @@ clear_stash () {\n create_stash () {\n \tstash_msg=\"$1\"\n \n+\tgit update-index -q --refresh\n \tif no_changes\n \tthen\n \t\texit 0\n@@ -101,6 +102,7 @@ save_stash () {\n \n \tstash_msg=\"$*\"\n \n+\tgit update-index -q --refresh\n \tif no_changes\n \tthen\n \t\techo 'No local changes to save'\n@@ -150,6 +152,7 @@ show_stash () {\n }\n \n apply_stash () {\n+\tgit update-index -q --refresh &&\n \tgit diff-files --quiet --ignore-submodules ||\n \t\tdie 'Cannot restore on top of a dirty state'\n \n"},{"id":"89752","messageId":"20080904192008.6117@nanako3.lavabit.com","threadId":"15368","inReplyTo":"7v3akg5jul.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Re*: Peculiar behavior of git 1.5.6","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-09-04T10:20:08Z","receivedAt":"2008-09-04T10:20:08Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> In any case, I think this should fix the unrelated issue.\n>\n> -- >8 --\n> stash: refresh the index before deciding if the work tree is dirty\n>\n> Unlike the case where the user does have a real change in the work tree,\n> refusing to work because of unclean stat information is not very helpful.\n>\n> Signed-off-by: Junio C Hamano \n\nAcked-by: Nanako Shiraishi \n\n> ---\n> git-stash.sh | 3 +++\n> 1 files changed, 3 insertions(+), 0 deletions(-)\n>\n> diff --git c/git-stash.sh w/git-stash.sh\n> index e15c12a..d799c76 100755\n> --- c/git-stash.sh\n> +++ w/git-stash.sh\n> @@ -39,6 +39,7 @@ clear_stash () {\n> create_stash () {\n> \tstash_msg=\"$1\"\n> \n> +\tgit update-index -q --refresh\n> \tif no_changes\n> \tthen\n> \t\texit 0\n> @@ -101,6 +102,7 @@ save_stash () {\n> \n> \tstash_msg=\"$*\"\n> \n> +\tgit update-index -q --refresh\n> \tif no_changes\n> \tthen\n> \t\techo 'No local changes to save'\n> @@ -150,6 +152,7 @@ show_stash () {\n> }\n> \n> apply_stash () {\n> +\tgit update-index -q --refresh &&\n> \tgit diff-files --quiet --ignore-submodules ||\n> \t\tdie 'Cannot restore on top of a dirty state'\n> \n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"89772","messageId":"48C00751.3030102@lwfinger.net","threadId":"15368","inReplyTo":"7v3akg5jul.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: Re*: Peculiar behavior of git 1.5.6","fromName":"Larry Finger","fromEmail":"larry.finger@lwfinger.net","sentAt":"2008-09-04T16:05:37Z","receivedAt":"2008-09-04T16:05:37Z","isPatch":false,"sender":{"key":"larry.finger@lwfinger.net","avatar":null},"body":"Junio C Hamano wrote:\n> \n> But pull to merge codepath in question that Larry originally brought up\n> always did, and that is what puzzles me.\n> \n> Perhaps some virus scanner or trackerd is running under Larry's working\n> tree that contaminates the stat information after we refresh the index? I\n> dunno.\n\nNo, neither a virus scanner nor trackerd are running.\n\nI use quilt to handle my local patches. One of the things that I have \nfound confusing is that sometimes git complains about the files that \nhave been restored, and sometimes not.\n\nI replaced git on the machine in question with the latest git version \n(1.6.0.1.216.g1b23a) so the behavior will be the latest.\n\nThanks for the answers,\n\nLarry\n"}]}