Re*: Peculiar behavior of git 1.5.6

[Junio C Hamano <gitster@pobox.com>]

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