Jeff King wrote:
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html