When committing a text file in git, why could it be violating `.gitattribute` file?

Question

In one of my git repository, I have added the following .gitattribute file to regulate LF/CRLF characters:

*.bat text eol=crlf
*.cmd text eol=crlf
*.java text eol=lf
*.scala text eol=lf
*.xml text eol=lf
*.py text eol=lf
*.R text eol=lf

# mimicking apache spark

To test its effect, I manually change the line separator of one bat file from CRLF to LF, unfortunately, when committing & pushing this change in git, it is accepted despite obviously violating the new .gitattribute:

https://github.com/tek/splain/commit/9344551a1b61f0bf725cc2d9b8aecdced1e71c8b#diff-33fbd7a182c496726227993443a3cfea58670618db831c51c273dcd8962c861a

How could it be possible? Is it a bug in git?

Answer 1

This is intentional from Git. By itself, it will never convert line endings to CRLF when saving a file to its index. As soon as Git is told that a file extension is associated with text, it will take every oportunity to convert the line endings to LF when you stage something to be committed with that extension.

This can be explained by the fact that git was initilally developed for Unix which uses LF. It's also a matter of consistency for git to deal with text in a uniform way internally when it comes to line endings.

This is usually not a problem since any use of the code in a repository should start with a proper git clone which performs the conversion according to the .gitattributes, so that line endings are correctly specified in the working directory.

But in some special case where you really need to make git save line endings as CRLF, you can have a look at this answer.