On Tue, Aug 09, 2016 at 07:49:38AM -0400, Jeff King wrote: > On Tue, Aug 09, 2016 at 11:33:37AM +0000, Torsten Bögershausen wrote: > > > > 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. > > The content of the file has been changed (we appended the letter 'Z' to it, > > so even if mtime is the same, st.st_size should differ. > > And it seems as if the commit is triggered, see below. > > I don't think I made myself clear. It's not a question of whether there > is something to commit. It's that when git asks the index "what is the > sha1 of the content at this path?", the index may be able to answer > directly (the file is up-to-date, so we return the index value), or it > may have to go to the filesystem and read the file content. It is this > latter which triggers convert_to_git(), which is what generates the > message in question. > > For a more stripped-down example, try: > > git add foo > git commit -m msg > > versus: > > git add foo > sleep 1 > git commit -m msg > > In the latter case, we should not generally need convert_to_git() in the > "commit" step. It was already done by "git add", and we reuse the cached > result. > > Whereas in the first one, we may run into the racy-index problem and > have to re-read the file to be on the safe side. > > -Peff Thanks for the explanation, so there are 2 chances for a race. I assume that the suggested "touch" will fix race#2 in most cases. In my understanding, the change of the file size will be more reliable: diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh index 2860d2d..9933a9b 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 && + printf Z >>"$fname" && git -c core.autocrlf=$crlf commit -m "commit_$fname" $fname >"${pfx}_$f.err" 2>&1 done ------------------- Does anybody agree ? And, by the way, the convert warning may be issued twice, once in "git add" and once in "git commit". -- 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