2014-02-15

Time to Kill the Carriage Return


It is now 2014 and time to kill the carriage return in line endings. Cross platform development is normal and it makes sense to standardize on LF (line feed) instead of CRLF (carriage return, line feed) for line endings. Visual Studio and other IDEs and text editors on Windows are able to handle LF line endings just fine. Why Windows uses CRLF is documented on Wikipedia. When MS-DOS came out in 1981, it adopted the workaround used by other systems for making Teleprinters work.When Windows came out in 1985, it continued this workaround. Times have changed.

Git

Git is becoming the dominant source code management (SCM) system thanks to sites like GitHub. Google, Microsoft, and Apple have all integrated it into their products. It is now standard practice to use a .gitattributes file with text=auto set in order to normalize line endings in the Git repository. It is in the Visual Studio defaults, GitHub docs, and Scott Hanselman's blog from a year ago (image above is from this). With text=auto, all source code is stored in the Git repository with LF line endings. Git gets rid of the carriage returns and normalizes its repository to just line feeds.

By default, the working directory should match what is in the repository. When you don't use .gitattributes file, this is the default behavior. With .gitattributes and text=auto, this was the default behavior until recently due to "fixes" related to issue git#57. Instead of changing the behavior to match what they interpreted the meaning of the docs to be, the fix should have been to fix ambiguity in the docs. Here is what the docs currently say:

https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

https://www.kernel.org/pub/software/scm/git/docs/git-config.html

text=auto Should be

The fix should be to change the docs for text=auto to read:

This ensures that all files that git considers to be the text will have normalized (LF) line endings in the repository. If core.autocrlf=true, core.eol will be used to normalize the files in your working directory. core.eol defaults to native line endings for your platform.

text=auto Currently

Documentation for the current (wrong) behavior should read:

This ensures that all files that git considers to be the text will have normalized (LF) line endings in the repository.  The default value for core.autocrlf is "true". core.eol will be used to normalize the files in your working directory unless core.autocrlf is set to "input". core.eol defaults to native line endings for your platform.

Source Linking

With the current (wrong) behavior, it is not possible to source link libraries built on Windows that are using the default settings. The checksums of the files stored in the pdb files do not match what GitHub and others provide on their raw URLs, since the raw files match what is in the repository. Changing files to not match what is in the repository should be the exception, not the default.

To allow source linking on Windows, I recommend setting the source code files to LF in the .gitattributes file (example). This will guarantee that working directory files are LF too and source linking will work on the build machines and all machines. It is time to kill the carriage return.