On Tue, Feb 20, 2018 at 08:42:26AM -0500, Matt McCutchen wrote: > I noticed that if a file subject to a safecrlf warning is added to the > index in the same second that it is created, resulting in a "racily > clean" index entry, then a subsequent "git add" command prints another > safecrlf warning. I reproduced this on the current "next" > (499d7c4f91). The procedure: > > $ git init > $ git config core.autocrlf true > $ echo foo >file1 && git add file1 && git add file1 > warning: LF will be replaced by CRLF in file1. > The file will have its original line endings in your working directory. > warning: LF will be replaced by CRLF in file1. > The file will have its original line endings in your working directory. > $ echo bar >file2 && sleep 1 && git add file2 && git add file2 > warning: LF will be replaced by CRLF in file2. > The file will have its original line endings in your working directory. > > This came up when I ran the test suite for Braid on Windows > (https://github.com/cristibalan/braid/issues/77).
I think a .gitattributes file could/should be used. I'll answer there seperatly. > > The phenomenon actually seems to be more general: touching the file > causes the next "git add" to print a safecrlf warning, suggesting that > the warning occurs whenever the index entry is dirty. One could argue > that a new warning is reasonable after touching the file, but it seems > clear that "racy cleanliness" is an implementation detail that > shouldn't have user-visible nondeterministic effects. > > In either case, if "git update-index --refresh" (or "git status") is > run before "git add", then "git add" does not print the warning. On > the other hand, if line endings in the working tree file are changed, > then git shows the file as having an unstaged change, even though the > content that would be added to the index after CRLF conversion is > identical. So it seems that git remembers the pre-conversion file > content and uses it for "git update-index --refresh" and would just > need to use it for "git add" as well. > > Thoughts about the proposed change? Does someone want to work on it or > give me a pointer to where to get started? Good analyzes, thanks for that. I don't hava a pointer, but what should happen ? 2 warnings for 2 "git add" should be OK, I think. 1 warning is part of the optimization, that Git does to handle hundrets and thousands of files efficciently. Is the 1/2 warning real live problem ? > > Thanks, > Matt
