-1

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?

tribbloid
  • 4,026
  • 14
  • 64
  • 103
  • The `text` and `eol` attribute docs tell you the effects they'll have: convert line endings to LF on `add`, convert to whatever `eol` and your platform say on checkout. Can you point out whatever it was that led you to expect anything different? – jthill Jun 05 '23 at 21:47
  • https://git-scm.com/docs/gitattributes#_eol says that it only has effect when the files are checked out. It won't prevent you from committing something that has different line endings than specified. – apokryfos Jun 05 '23 at 22:00

1 Answers1

2

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.

DecimalTurn
  • 3,243
  • 3
  • 16
  • 36
  • That's a good explanation, but I have to say it is a very strange design: Imagine thousands of delta being indexed and persisted on git without any content change :) – tribbloid Jun 07 '23 at 20:53