I’ve read a lot of different questions and answers on Stack Overflow as well as git documentation on how the core.autocrlf setting works.
This is my understanding from what I’ve read:
Unix and Mac OSX (pre-OSX uses CR) clients use LF line endings.
Windows clients use CRLF line endings.
When core.autocrlf is set to true on the client, the git repository always stores files in LF line ending format and line endings in files on the client are converted back and forth on check out / commit for clients (i.e. Windows) that use non-LF line endings, no matter what format the line endings files are on the client (this disagrees with Tim Clem’s definition – see update below).
Here is a matrix that tries to document the same for the ‘input’ and ‘false’ settings of core.autocrlf with question marks where I’m not sure of line ending conversion behavior.
My questions are:
- What should the question marks be?
- Is this matrix correct for the “non-question marks”?
I’ll update the question marks from the answers as consensus appears to be formed.
core.autocrlf value
true input false
----------------------------------------------------------
commit | convert ? ?
new | to LF (convert to LF?) (no conversion?)
commit | convert to ? no
existing | LF (convert to LF?) conversion
checkout | convert to ? no
existing | CRLF (no conversion?) conversion
I’m not really looking for opinions on the pros and cons of the various settings. I’m just looking for data which makes it clear how to expect git to operate with each of the three settings.
—
Update 04/17/2012: After reading the article by Tim Clem linked by JJD in the comments, I have modified some of the values in the “unknown” values in the table above, as well as changing “checkout existing | true to convert to CRLF instead of convert to client”. Here are the definitions he gives, which are more clear than anything I’ve seen elsewhere:
core.autocrlf = false
This is the default, but most people are encouraged to change this
immediately. The result of using false is that Git doesn’t ever mess
with line endings on your file. You can check in files with LF or CRLF
or CR or some random mix of those three and Git does not care. This
can make diffs harder to read and merges more difficult. Most people
working in a Unix/Linux world use this value because they don’t have
CRLF problems and they don’t need Git to be doing extra work whenever
files are written to the object database or written out into the
working directory.
core.autocrlf = true
This means that Git will process all text files and make sure that
CRLF is replaced with LF when writing that file to the object database
and turn all LF back into CRLF when writing out into the working
directory. This is the recommended setting on Windows because it
ensures that your repository can be used on other platforms while
retaining CRLF in your working directory.
core.autocrlf = input
This means that Git will process all text files and make sure that
CRLF is replaced with LF when writing that file to the object
database. It will not, however, do the reverse. When you read files
back out of the object database and write them into the working
directory they will still have LFs to denote the end of line. This
setting is generally used on Unix/Linux/OS X to prevent CRLFs from
getting written into the repository. The idea being that if you pasted
code from a web browser and accidentally got CRLFs into one of your
files, Git would make sure they were replaced with LFs when you wrote
to the object database.
Tim’s article is excellent, the only thing I can think of that is missing is that he assumes the repository is in LF format, which is not necessarily true, especially for Windows only projects.
Comparing Tim’s article to the highest voted answer to date by jmlane shows perfect agreement on the true and input settings and disagreement on the false setting.
