Peculiar behavior of git 1.5.6

Peculiar behavior of git 1.5.6

[Larry Finger]

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?

Thanks,

Larry

Re: Peculiar behavior of git 1.5.6

[Johannes Sixt]

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.)

-- Hannes

Re: Peculiar behavior of git 1.5.6

[Junio C Hamano]

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...

Re: Peculiar behavior of git 1.5.6

[Jonathan del Strother]

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"

Re*: Peculiar behavior of git 1.5.6

[Junio C Hamano]

"Jonathan del Strother" <maillist@steelskies.com> writes:

> 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.
>>> ...
>>> 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"

That one is unfortunately completely an unrelated issue.  "stash apply"
never refreshed the index on its own.

But pull to merge codepath in question that Larry originally brought up
always did, and that is what puzzles me.

Perhaps some virus scanner or trackerd is running under Larry's working
tree that contaminates the stat information after we refresh the index?  I
dunno.

In any case, I think this should fix the unrelated issue.

-- >8 --
stash: refresh the index before deciding if the work tree is dirty

Unlike the case where the user does have a real change in the work tree,
refusing to work because of unclean stat information is not very helpful.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-stash.sh |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git c/git-stash.sh w/git-stash.sh
index e15c12a..d799c76 100755
--- c/git-stash.sh
+++ w/git-stash.sh
@@ -39,6 +39,7 @@ clear_stash () {
 create_stash () {
 	stash_msg="$1"
 
+	git update-index -q --refresh
 	if no_changes
 	then
 		exit 0
@@ -101,6 +102,7 @@ save_stash () {
 
 	stash_msg="$*"
 
+	git update-index -q --refresh
 	if no_changes
 	then
 		echo 'No local changes to save'
@@ -150,6 +152,7 @@ show_stash () {
 }
 
 apply_stash () {
+	git update-index -q --refresh &&
 	git diff-files --quiet --ignore-submodules ||
 		die 'Cannot restore on top of a dirty state'
 

Re: Re*: Peculiar behavior of git 1.5.6

[Larry Finger]

Junio C Hamano wrote:
> 
> But pull to merge codepath in question that Larry originally brought up
> always did, and that is what puzzles me.
> 
> Perhaps some virus scanner or trackerd is running under Larry's working
> tree that contaminates the stat information after we refresh the index?  I
> dunno.

No, neither a virus scanner nor trackerd are running.

I use quilt to handle my local patches. One of the things that I have 
found confusing is that sometimes git complains about the files that 
have been restored, and sometimes not.

I replaced git on the machine in question with the latest git version 
(1.6.0.1.216.g1b23a) so the behavior will be the latest.

Thanks for the answers,

Larry

Re: Re*: Peculiar behavior of git 1.5.6

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>:

> In any case, I think this should fix the unrelated issue.
>
> -- >8 --
> stash: refresh the index before deciding if the work tree is dirty
>
> Unlike the case where the user does have a real change in the work tree,
> refusing to work because of unclean stat information is not very helpful.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Acked-by: Nanako Shiraishi <nanako3@lavabit.com>

> ---
>  git-stash.sh |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git c/git-stash.sh w/git-stash.sh
> index e15c12a..d799c76 100755
> --- c/git-stash.sh
> +++ w/git-stash.sh
> @@ -39,6 +39,7 @@ clear_stash () {
>  create_stash () {
>  	stash_msg="$1"
>  
> +	git update-index -q --refresh
>  	if no_changes
>  	then
>  		exit 0
> @@ -101,6 +102,7 @@ save_stash () {
>  
>  	stash_msg="$*"
>  
> +	git update-index -q --refresh
>  	if no_changes
>  	then
>  		echo 'No local changes to save'
> @@ -150,6 +152,7 @@ show_stash () {
>  }
>  
>  apply_stash () {
> +	git update-index -q --refresh &&
>  	git diff-files --quiet --ignore-submodules ||
>  		die 'Cannot restore on top of a dirty state'
>  

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/