On Tue, Aug 09, 2016 at 02:51:10AM -0400, Jeff King wrote:

>   - index raciness causing us to avoid reading file content. For
>     example, if you do:
>       echo foo >bar
>       git add bar
>     Then _usually_ "bar" and the index will have the same mtime. And
>     therefore subsequent commands that need to refresh the index will
>     re-read the content of "bar", because they cannot tell from the stat
>     information if we have the latest version of "bar" in the index or
>     not (it could have been written after the index update, but in the
>     same second).
>     But on a slow or heavily loaded system (or if you simply get unlucky
>     in crossing the boundary to a new second), they'll have different
>     mtimes. And therefore git knows it can skip reading the content from
>     the filesystem.
>     So if your test relies on git actually re-converting the file
>     content, it would sometimes randomly fail.
> The second one seems plausible, given the history of issues with
> changing CRLF settings for an existing checkout. I'm not sure if it
> would be feasible to reset the index completely before each tested
> command, but that would probably solve it.

And indeed, this seems to fix it for me (at least it has been running in
a 16-way loop for 5 minutes, whereas before it died after 30 seconds or

diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 2860d2d..9f057ff 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -120,6 +120,7 @@ commit_chk_wrnNNO () {
                cp $f $fname &&
                printf Z >>"$fname" &&
                git -c core.autocrlf=$crlf add $fname 2>/dev/null &&
+               touch $fname && # ensure index raciness
                git -c core.autocrlf=$crlf commit -m "commit_$fname" $fname 
>"${pfx}_$f.err" 2>&1

I'm not sure if there is a more elegant solution, though (for instance,
why not collect the output from "git add", which should have the same
warning, I would think).

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to