Jeff King wrote:
quoted text
> which dumped me with a shell in the "broken" state. The interesting
> thing is that I can then repeatably run "git diff two" and get an empty
> diff.  So I don't think the error or race condition is in the run of
> "git diff" itself, but rather what happened above (presumably the in
> the read-tree step).

This, and Jonathan's observation about git-apply, finally got me
somewhere.  The issue is that the index file has a timestamp different
from the saved mtimes of the file itself.  This can be provoked
deterministically by the patch below, even without valgrind; valgrind
merely makes it much more likely to happen by slowing down
git-read-tree.

Now I don't know what the next step in the chain is.  Who's the
resident expert on index raciness?  Does git-diff then reindex the
file, and in doing so, change the index entry?


diff --git i/t/t0025-crlf-auto.sh w/t/t0025-crlf-auto.sh
index f5f67a6..7a9cd3a 100755
--- i/t/t0025-crlf-auto.sh
+++ w/t/t0025-crlf-auto.sh
@@ -46,6 +46,8 @@ test_expect_success 'crlf=true causes a CRLF file to be normalized' '
 	echo "two crlf" > .gitattributes &&
 	git read-tree --reset -u HEAD &&
 
+	test-chmtime +1 .git/index &&
+
 	# Note, "normalized" means that git will normalize it if added
 	has_cr two &&
 	twodiff=`git diff two` &&
@@ -58,6 +60,8 @@ test_expect_success 'text=true causes a CRLF file to be normalized' '
 	echo "two text" > .gitattributes &&
 	git read-tree --reset -u HEAD &&
 
+	test-chmtime +1 .git/index &&
+
 	# Note, "normalized" means that git will normalize it if added
 	has_cr two &&
 	twodiff=`git diff two` &&

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html