Showing results for 
Search instead for 
Did you mean: 
Copilot Lvl 3
Message 1 of 4

git config core.autocrlf should default to false

And this should be configurable in the checkout action. The default should be false; otherwise a git checkout on Windows will often try to turn LF line endings into CRLF, which can easily break fragile files, such as expected output files for tests.


See for the same thread over on Travis CI, which never got a fix.


I had to work around this with a .gitattributes file as follows:


* -text
3 Replies
GitHub Staff
Message 2 of 4

Re: git config core.autocrlf should default to false

Configuring your line endings with a .gitattributes file is the correct thing to do here, as that is the only way to check line ending configuration into the repository.


There has been mixed guidance throughout the years about the recommendations for core.autocrlf, but most has suggested core.autocrlf=true.  Most importantly, Git for Windows sets core.autocrlf=true in its installer.  Therefore, we too set core.autocrlf=true as our default.


However, you should not rely on core.autocrlf settings, you should configure the behavior you want with a .gitattributes file.  This is the only way to reliably deal with line endings in a repository.

Copilot Lvl 3
Message 3 of 4

Re: git config core.autocrlf should default to false

Thanks for the reply. Good to know that at least this was a deliberate decision.


I still think this is the wrong decision to make, though. autocrlf is for humans, but GitHub Actions is not a human. It should check out a repository *exactly* as it was found.


I'd argue the opposite; if anyone really wants autocrlf to happen on CI, they should turn it on somehow.


Put it another way, I have dozens of repositories that have had zero need for a gitattributes file, but now this decision is forcing me to add the file everywhere, cluttering the repositories.

Copilot Lvl 2
Message 4 of 4

Re: git config core.autocrlf should default to false

Fully agree with the OP. This setting is very cumbersome and we would like to be able to configure it as well, so we can deactivate it again.