Coder Perfect

Git on Windows: What do the crlf settings mean?


I’m baffled by the intricacies of git’s CrLf settings: core.autocrlf, core.safecrlf.

I’m working on a cross-platform project with a group of people, and I’d like both Windows and Linux devs to be able to collaborate without git flagging files as updated based on line ending style.

What do the different options mean? What would the ramifications be if you choose any of the options? And what would be the best course of action in my situation?

Yes, I’m aware of this question, and the responses were uninformative and hence unhelpful.

Asked by Jonathan Livni

Solution #1

The three autocrlf values are:

Note that content that is already in the repository will not be affected by autocrlf. If you’ve previously committed something with CRLF endings, they’ll remain that way. This is an excellent reason to avoid relying on autocrlf: if one user doesn’t have it enabled, they can add content with CRLF endings to the repository, and it will stay there. The text property can be used to compel normalization; setting it to auto for a path will mark it for end-of-line normalization, presuming git determines the content is text (not binary).

Safecrlf is a related option that basically ensures you don’t convert a binary file to CRLF in an irreversible manner.

I don’t have a lot of experience with Windows and git, so any feedback on the implications or problems would be really appreciated.

Answered by Cascabel

Solution #2

I looked at three different values for commit and checkout cases and came up with the following table:

║ core.autocrlf ║     false    ║     input    ║     true     ║
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║

Across all platforms, I propose using core.autocrlf = input. In this instance, if Git encounters CRLF, it will convert it to LF implicitly, and existing files with LF will remain unchanged.

Answered by pratt

Solution #3

CRLF is the default line ending in Windows, while LF is the default in Linux. Please see the table below for a better understanding.

The symbol * highlights the differences between Windows and Unix in the given table of data. The CLRF information based on OS platforms is summarized below:

Answered by Srikanth Popuri

Post is based on