For an explanation of what Git's core.*crlf setting, see or or just man git-config. As the appropriate settings are dependent on the user's OS, we should do some OS sniffing and provide customized recommendations based on that. Of course we should also link to a place with the full instructions and make clear that these instructions are OS-specific and based on unreliable sniffing.

For clarity, we're recommending core.autocrlf and core.safecrlf settings, and what gitimmersion recommends are safe & sane.


kndr’s picture

Thanks for clarification.
Place with the full instructions should be created. For example, on page for patch contributors there is recommended .gitconfig but there is no suggestions about core.autocrlf and core.safecrlf, which are very important.


Also, for Unix/Mac users:
git config --global core.autocrlf input
git config --global core.safecrlf true

And for Windows users:
git config --global core.autocrlf true
git config --global core.safecrlf true

dww’s picture

Is this for drupalorg or project_git_instructions?

kndr’s picture

Hm. Indeed. Project_git_instructions would be better place for this clarifications, I think. This thread was the only, I found about this bunch of settings in .gitconfig. Git's core.*crlf setting will be the most usefull for patch contributors, in my opinion.

dww’s picture customizations» Project Git instructions
Version:6.x-3.x-dev» 6.x-1.x-dev

Moving there for now...

scor’s picture

Are these official guidelines yet? There is this comment at the bottom of the Patch workflows handbook page, but since it's a comment it's potentially confusing for users to know whether they should use these settings or not. I'm personally not using these settings and I've had no problems so far, but that's probably because I've never run across any project with CRLF line endings...

benjifisher’s picture

The Calendar project includes some files with CRLF line endings. This is because RFC 2445 (the ical specification) requires CRLF, so the template files (.tpl.php) that are used for ical feeds need CRLF. (There are also a lot of

print $foo . "\r\n";


Setting core.autocrlf to input (on Mac or Linux) causes major headaches. Patches produced with one setting do not apply when the other setting is used. (To my surprise, it is the setting when invoking git apply that matters.) If you insist on setting core.autocrlf to input, you may end up with an ical feed that fails to validate because of CRLF issues. See #1284170-11: All-day events missing or wrong in ical feed.

benjifisher’s picture

I think I have found a solution to the problems I described in #6. In projects that have to use some files with CRLF endings, add a .gitattributes file with a line like

*.tpl.php -text

This example tells git not to do any line-ending conversion on the template files. See #1302052: CRLF line endings cause problems with "git apply".

I would appreciate comments from people who know git better than I do.

kay_v’s picture

Page for complete set of recommended .gitcontrib settings:

Interestingly, the crlf settings are significantly different from those recommended by gitimmersion (and quoted by @kndr)

kndr’s picture

In the meantime, I've changed the settings. I work for some time on the settings indicated on the page I confirm that core.autocrlf and core.safecrlf should be set to FALSE. Otherwise, there is a lot of problems that I experienced. In the Windows environment, you should simply use the appropriate settings in text editors. In my opinion there is no other way.

eliza411’s picture

Status:Active» Closed (won't fix)

I don't think there's been enough support issues generated by this to add complexity to the Version control tab, so I'm marking this as closed, won't fix. I think the regular documentation is coverage enough. If I'm mistaken, please point me to the other issues and re-open.