git quirk: core.autocrlf

David A. Wheeler dwheeler at dwheeler.com
Tue Apr 23 19:37:51 UTC 2024



> On Apr 21, 2024, at 8:00 PM, James Addison via rb-general <rb-general at lists.reproducible-builds.org> wrote:
> 
> ...
> That universal newline handling may cause problems in some cases if
> not handled carefully, but surprisingly -- at least to me -- 'git'
> itself also automatically converts the line-endings of files to the
> local platform's standard.

This is configurable, and I recommend turning it off. Today you typically
don't need to try to force data to the local convention.

It made sense when on Windows, because some tools - especially Notepad -
couldn't handle Unix lines. This created *endless* problems.
However, as of 2018, Notepad added support for Unix line endings:
https://devblogs.microsoft.com/commandline/extended-eol-in-notepad/

Most other tools quietly accept either format.
E.g., vim prefers Unix line endings, but if a file has only MSDOS|Windows|CP/M line endings
of \r\n, it will accept it and save revisions in that format:
https://vim.fandom.com/wiki/File_format#:~:text=File%20format%20detection,-The%20'fileformats'%20option&text=Vim%20will%20look%20for%20both,ff'%20option%20will%20be%20dos.

I prefer creating stuff using Unix line-endings (\n), but if I clone a Windows repo,
most of the tools will quietly use that other format, and I wouldn't normally even notice.

This kind of thing *can* create mysterious reproduction problems, so I think it's in scope
for this mailing list.

--- David A. Wheeler



More information about the rb-general mailing list