Matt McCutchen <matt@xxxxxxxxxxxxxxxxx> writes: > ... 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. Correct. The cached-stat information is meant to be compared with the size on the filesystem. Based on your observation, it seems that what you are seeing is not specific to safe-crlf thing. If you reconfigure anything that affects the checkout conversion codepath, including the "smudge" filter, an entry in the index that used to be up-to-date will still have cached-stat info like timestamp and size that match the on-disk file, even though if you _were_ to check it out afresh out of the index, the reconfigured checkout codepath may produce different file contents on-disk. A consequence of this is that you may cause Git to still say that the path is clean, even though it is no longer true. There is no single "right" solution out of this situation, as it depends on the reason why you made such a reconfiguration in the first place. - If the reason is because you found that what is stored in the index is correct but their contents are checked out incorrectly (e.g. both the index and the working tree files end their lines with LF, but you want your working tree files to be converted to CRLF, and you futzed with .gitattributes or core.crlf), then you would want to "correct" it by checking them out, bypassing the "if the cached-stat information says we already have the matching contents on disk, do not write the file out" optimization. - If the reason is the other way around, then you would want to "correct" the indexed contents by rehashing what you have on disk. Perhaps a recently added "git add --renormalize" is what you are looking for.
