On Tue, 2018-02-20 at 08:42 -0500, Matt McCutchen wrote: > 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.
On further testing, this analysis is wrong. What I was seeing is that if the size of the working tree file has changed, git reports an unstaged change. (I suppose that reporting an unstaged change in this case without checking whether the post-conversion content has changed may be an important optimization.) If the line endings are changed without changing the size or post-conversion content, then no unstaged change is reported. It does not appear that git saves the pre- conversion content. Thus, if it were possible to create a file that doesn't need a safecrlf warning, add it to the index, and then modify it so that it does need a safecrlf warning without changing the size or post-conversion content, we would have a bug where no warning is shown in the case where "git status" is run before the second "git add". I believe this bug can't occur in the particular case of CRLF conversion without other filters because the file that doesn't need a safecrlf warning has a unique minimum (LF) or maximum (CRLF) size, though I presume it could occur with custom filters. My proposal would then be that "git add" should not show a safecrlf warning if the size and post-conversion content haven't changed; it would merely bring "git add" to parity with the potential bug in the "git status" case. Matt
