Share
Tweet
Share
Share

Overview

Git is an incredibly powerful version control system with a myriad of features and capabilities, including the ability to work across various OS platforms, including Windows and Unix.

I recently started working on a project along with several other developers using various operating system platforms. We came across an issue relating to the handling of LF / CRLF line ending characters between the various operating system platforms.

In this article we’ll take a look at how to deal with line ending characters in git.

GitHub Icon

Possible Solutions

Windows uses a different set of characters (CRLF) to signify a line ending compared with Unix (LF). This can lead to unpredictable and hard to diagnose issues if you are working in a team of multiple developers or working across multiple server operating system platforms.

Git offers a couple of different approaches for dealing with line ending characters, including:

  • Option 1: Use git config setting ‘core.autocrlf’ (legacy approach)
  • Option 2: Using .gitattributes (recommended)

Let’s dive into each of these options a bit further …

TLDR; If you’re short on time then feel free to jump straight to Option 2, as it’s generally considered the best approach.

Option 1: ‘core.autocrlf’ git config (legacy approach)

Git originally introduced ‘core.autocrlf’ configuration setting to instruct git on how to deal with end of line (eol) characters. By default, this value is set to ‘false’ in new git installations.

Setting this to ‘true’ will instruct git to automatically convert line ending characters. If you are on a Windows machine then git will automatically convert LF to CRLF upon check-out. The line endings are later converted back to Unix style line endings (LF) when committing the files for compatibility.

git config core.autocrlf true

Whilst this solution will work well in a single developer environment. It is not recommended in a multi-developer environment, as it relies on all developers in the team to explicitly configure their git configuration, which may not always happen. For this reason, Option 2 is recommended in a multi-developer environment.

Option 2: Using .gitattributes (Recommended)

Git later introduced another approach to handling line endings by adding a .gitattributes file into your repo which specifies the line ending format to be used for a given file type. If you’re interested in learning more, then you can find more detailed information here – https://git-scm.com/docs/gitattributes#_text.

Below is an example .gitattributes file to demonstrate. Additionally, you can also see some more sample files here – https://github.com/sbartholomeusz/git-actions-az-deploy-demo.

# Set default behavior
* text=auto

# Always use windows line endings
*.sln text eol=crlf

Once you’ve created the .gitattributes file, you can verify this change by running the below git commands:

λ git check-attr -a "readme.md"
---------------------------------
readme.md: text: set
readme.md: eol: crlf
λ git ls-files --eol
---------------------------------
i/lf w/lf attr/ .gitattributes
i/lf w/crlf attr/ readme.md

Note: The first column refers to the line endings contained in the ‘index’, and the second column refers to the line endings contained in the ‘working directory’

Recommendation

As a general rule, I’d recommend always using option 2 (.gitattributes file), as it enables you to capture all required configuration in source control, rather than needing to rely on developers within your team to explicitly configure git, therefore it works well in either a single or multi-developer environment.

Also, try to stay away from using both these approaches together as it is more than likely to create confusion and lead to issues.

Final Thoughts

Well, I hope you’ve learned something from this article. If you have any other tips for handling end-of-line characters with Git, then feel free to share them below in the comments.

Happy coding! 😊

Shane Bartholomeusz
Latest posts by Shane Bartholomeusz (see all)
Share
Tweet
Share
Share