core.autocrlf vs. .gitattribute

Hello all,

I’ve been struggling with this issue for quite some time, tried several tips from here and stack overflow. Finally, I found some sort of workaround, but still there is something that bothers me. 

The project in question is a mixed platform (both Windows and Linux). All text files are normalized in the repository (they were all committed with LF). The objective:

  • text files in the working folder should always have CRLF on Windows and LF on Linux.
  • .gitattributes should always have precedence, regardless of core.autocrlf and core.eol

Page https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings#global-settings-for-line-endings

says: “When you commit this file to a repository, it overrides the core.autocrlf setting for all repository contributors.” The underlined commit is mine.

That’s exactly what I need, so I put the following line in my .gitattributes:

* text=auto

After several experiments, I found that during checkout, core.autocrlf overrides .gitattributes as follows:

  • when core.autocrlf = input, files checked out on Windows have LF line terminators. 
  • when core.autocrf = true, files checked out on Linux have CRLF line terminators.

My current workaround is to make sure that all the machines have both core.autocrlf and core.eol not set, but that’s not convenient when machines are too many (not my case, fortunately). 

The question:

How do I ignore the machine settings also while checking files out? Not only during commit, as stated above.

Thanks in advance.

1 Like

Hi nippurdelagash! :wave:

If you’ve set up a .gitattributes file then that should override the machine’s local core.autocrlf settings - it’s strange that that hasn’t worked for you!

Did the .gitattributes file get pushed up to GitHub, and subsequently downloaded to each local copy?

Did you specify which files should be treated as text? Eg,

*.cs text
*.json text
*.html text

Did you go through the process to normalize all the files after introducing the .gitattributes file?

Ah, actually, while looking into this I have discovered that there may have been some recent-ish changes to how this works:

So it looks like now setting core.autocrlf to true or input overrides core.eol:

https://git-scm.com/docs/gitattributes#_text

Does that explain the behavior you’re seeing?

Hello @yamiacat, thanks for answering.

I did all the experiments using a local repository, but it should work the same on GitHub. And yes, I did push .gitattributes to the repo and it was always downloaded to each working copy.

No, I did not specify the text files, but did something equivalent. Since git is pretty smart detecting text files, I put the line

  • text=auto

and then explicitly declared all the binary extensions (*.jpg, *.exe, *lib, etc).

Yes, I did follow the renormalization process as indicated in the manual. I double-checked all the text files, and they are correctly normalized in the repository.

I also get the same results that are summarized in the Stack Overflow link that you mention.

I do not use core.eol, actually I made sure it is unset everywhere, to let git use the default EOL terminator on each platform. All in all, I suspect this could be just a documentation issue: when you read that .gitattributes overrides core.autocrlf you might think it means “bidirectional” (both checkin and checkout), but most likely the override takes place only at checkin time.