You are here:Home»KB»Programming»Line endings when working with Git for Windows and VSCode
Sunday, 11 May 2025 09:19

Line endings when working with Git for Windows and VSCode

Written by

So you are installing `Git for Windows` and you are asked how to handle line endings, what option should I pick and why? I will answer this question here so you know what to choose and why rather than just following a YouTube video than never explains anything except just click next because this is what I use.

The information here applies to handling EOL in Git and probably applies to people whoe's OS is not Windows such as MacOS and Linux.

Summaries

Where I can change line endings when using Git for Windows and VSCode? (each overrides the last)

Settings precedence - User and workspace settings | Visual Studio Code

  1. VSCode (User settings) (%APPDATA%\Code\User\settings.json)
    • Action: Set EOL for new files.
    • Scope: All Workspaces.
    • Additional:
      • Command Palette ( F1 | Ctrl+Shift+P) --> Preferences: Open User Settings --> `Files: Eol`: LF
      • Settings --> Text Editor --> Files --> Eol: LF
      • Profiles replace the `User settings`, if loaded.
      • These settings are only per user which means they are local and are not shared.
  2. VSCode (Workspace settings) (.vscode/settings.json)
    • Action: Set EOL for new files.
    • Scope: Workspace.
    • Additional:
      • These settings can be commited to a repo and thus can be shared between colleagues and the wider world.
  3. VSCode (Multi-Root Workspace / Workspace Folder setting) (.vscode/.code-workspace)
    • Action: Set EOL for new files.
    • Scope: Specified Workspace Folders.
    • Additional:
      • Settings for a particular folder can be saved in the .code-workspace.
      • These settings can be commited to a repo and thus can be shared.
  4. VSCode (Multi-Root Workspace) ([Workspace Folder]/.vscode/settings.json)
    • Action: Set EOL for new files.
    • Scope: Workspace Folder
    • Additional:
      • These settings can be commited to a repo and thus can be shared.
  5. Git (Repository) (.editorconfig)
    • Action: Set EOL for new files.
    • Scope: Git repository.
    • Additional:
      • Visual Studio = Full native support, VS will check your code on every code change.
      • VSCode = Partial support is added by extensions.
  6. VSCode (Extensions) - Examples below:
    1. Auto Convert End Of Line - Visual Studio Marketplace
      • Action: Change the EOL for all text files, on save
      • Scope: Workspace
    2. Prettier - Code formatter - Visual Studio Marketplace
      • Action: Change the EOL for all files, as specified (see below) on save
      • Scope: Workspace
      • Additional:
        • You can use VS Code settings to configure prettier. Settings will be read from (listed by priority):
        • NOTE: If any local configuration file is present (i.e. .prettierrc) the VS Code settings will NOT be used.
        • The VS Code settings are meant to be used as a fallback and are generally intended only for use on non-project files.
        • It is recommended that you always include a prettier configuration file in your project specifying all settings for your project.
        • If options.editorconfig is true and an .editorconfig file is in your project, Prettier will parse it and convert its properties to the corresponding Prettier configuration. This configuration will be overridden by .prettierrc, etc. Currently, the following EditorConfig properties are supported:
          • end_of_line
          • indent_style
          • indent_size
          • tab_width
          • max_line_length
        • End of Line - Options · Prettier - Prettier ships with a handful of format options.
        • Unlocking Prettier: Mastering End of Line Configuration | runebook.dev
          • Inconsistent EOL characters can lead to unnecessary Git conflicts, making it harder to track changes and collaborate effectively.
          • Prettier aims to enforce consistent code style across a project or team. This includes standardizing how line endings are represented.
          • This article covers .prettierrc and .gtiattributes
    3. ESLint - Linter - Visual Studio Marketplace
      • Action: Change the EOL for all files, as specified (see below) on save
      • Scope: Workspace
    4. EditorConfig for VS Code - Visual Studio Marketplace
      • Action: Change the EOL for all files, as specified in .editorconfig, on save
      • Scope: Workspace
      • Additional:
        • Supported Properties
          • indent_style
          • indent_size
          • tab_width
          • end_of_line (on save)
          • insert_final_newline (on save)
          • trim_trailing_whitespace (on save)
  7. Git (Repository) (.gitattributes)
    • Action: Change the EOL for all files
    • Scope: Git repository, but only on files as specified in the .gitattributes
    • Additional:
      • Applied when files are checked-in (submitted) to this Git repo.
  8. Git (Global Config / Git for Windows) (.gitconfig)
    • Action: Change the EOL for all files
    • Scope: All local Git repositories.
    • Additional:
      • Occurs when files are submitted or retrieved from any Git repo.
      • Only core.autocrf=true performs a conversion on EOLs during on Check-in and Checkout, all other settings are Checkin-in only.

 

How to enforce LF EOL (Windows --> VSCode --> Git)

Making the following changes to your Editor and Repo will ensure the best outcome

  • VSCode (User settings) (%APPDATA%\Code\User\settings.json)
    • Scope:
      • Set EOL LF for new files, for the User.
    • Actions:
      • Enable LF as the default EOL for the current VSCode User
        • Command Palette --> Preferences: Open User Settings --> `file end of line` --> `Files: Eol`: \n
          • It will indicate LF at the bottom of the dropdown, which is fine as this is is just a note.
  • VSCode (Workspace settings) (.vscode/settings.json)
    • Scope:
      • Set EOL LF for new files, for the Workspace.
    • Actions:
      • Enable LF as the default EOL for the VSCode Workspace
        • .vscode/settings.json 
          {
  "files.eol": "\n"
}

          Command Palette --> Preferences: Open Workspace Settings --> `file end of line` --> `Files: Eol`: \n

  • Git (Repository) (.editorconfig)
    • Scope:
      • Set EOL LF for new files, for the Git Repository.
      • Some VSCode extensions will use the EOL and apply upon save.
    • Actions:
      • Enable .editorconfig support (Visual Studio does not need this)
        • Install EditorConfig for VS Code
        • Not required if you use Prettier as this has supports, but you will need to make sure it is configured to respect .editorconfig however .prettierrc settings will always override .editorconfig values.
        • .editorconfig sets the EOL for new files but these VSCode extensions set the EOL on save.
      • Create .editorconfig 
        # EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file
root = true

# Default Behaviour
[*]
end_of_line = lf
  • VScode (Extensions) (.prettierrc) (Prettier)
    • Scope:
      • Can use .editorconfig or it's own settings, Set EOL LF for new files, for the Git Repository.
      • Some VSCode extensions will use the EOL and apply upon save.
    • Actions:
      • Create .prettierrc (only needed if using Prettier) 
        {
  "endOfLine": "lf"
}
  • VScode (Extensions) (eslint.config.js) (ESLint)
    • SCope
      • Can use .editorconfig or it's own settings, Set EOL LF for new files, for the Git Repository.
      • Some VSCode extensions will use the EOL and apply upon save.
    • Actions:
      • Create eslint.config.js (only needed if using ESLint) 
        import { defineConfig } from "eslint/config";

export default defineConfig([
  // Default Line Ending
  {
    files: ['**/*.*'],
    rules: {
      'linebreak-style': ['error', 'unix'],
    },
  },

  // Force batch scripts to always use CRLF line endings
  {
    files: ['**/*.[bB][aA][tT]', '**/*.[cC][mM][dD]'],
    rules: {
      'linebreak-style': ['error', 'windows'],
    },
  },

  // Force bash scripts to always use LF line endings
  {
    files: ['**/*.sh'],
    rules: {
      'linebreak-style': ['error', 'unix'],
    },
  },
]);
  • Git (Repository) (.gitattributes)
    • Scope
      • Enforce conversion of EOL to LF.
    • Actions:
      • Create .gitattributes (optional) 
        # Default Line Ending
* text=auto eol=lf
        • This will change all text file's EOL to LF when checking them into the repository, but not when you check them out in to your working tree (i.e. real files).
        • This is a fallback to enforce EOL before committing and should not be needed if everything in your repo is setup correctly.
        • Using this setting (* text=auto eol=lf) on it's own can cause corruption in some case, so a more granular .gitattributes configuration should be usedas Git can make mistakes with line endings, e.g. mixed EOL files and those with binary blobs
        • Use and this is a base reference and also consult further notes on this page.
        • * text=auto eol=lf is the same as * text=auto
        • This rule is doing the same for this repository as core.autocrf=input would do for the whole local Git instance.

 

EOL Handling Summary

  • General
    • DO NOT use core.autocrlf to normalise your line endings
      • This can lead to file corruption (i.e. embedded binary blobs in a text file)
      • You cannot assume everyone has set their Git development environment the same.
      • These settings would be global and thus a local repository would not have control and nor could you mandate changes with your editor.
    • Use .gitattributes and .editorconfig to configure line normalisation
      • These work on a Per-Repository basis.
      • This will allow you granular control of EOL.
      • Supports files with different EOL.
      • Support an individual file with mixed EOL.
      • The repository can define the EOL handling rather than individual user environments.
      • This is the professional way to setup a repository.
  • .git
    • Repo (check-in) = Commit = Submitted to Git
    • Working Tree (checkout) = The real files on your PC
  • .gitconfig
    • core.autocrlf=true
      • Converts text file's EOL to LF on check-in to the repo from the working tree.
      • Converts text file's EOL to CRLF on checkout from the repo to the working tree.
      • Tends to be recommended setting for Windows developers since it guarantees LF in the remote copy of your code while allowing you to use CRLF in your working tree for full compatibility with Windows editors and file formats.
      • This setting only needs be used in a Window environment, but can work in other OS.
    • core.autocrlf=input
      • Converts text file's EOL to LF on check-in to the repo from the working tree.
      • Leaves the working tree untouched.
      • This would be the same as: * text=auto eol=lf and * text=auto, but applied globally.
  • .gitattributes
    • Controls how EOL are handled when checking-in files to the Git repository.
    • Local files (Working Tree) and their EOL are unaltered by these settings.
    • Conflicts might occur when checking out files, but these can be resolved locally without poisoning the repo.
    • * text=auto eol=lf, * text=auto and core.autocrlf=input all do the same thing except core.autocrlf=input works at the Git server level and not on a per repository basis.
    • (untested) This file will override the core.autocrlf settings for specified files in this repository if an appropriate rule exists.
    • Using this file ensures a consistent behavior for all users, regardless of their Git settings and environment.
  • .editorconfig
    • An open, editor agnostic schema.
    • Defines the EOL for all new files.
    • Some VSCode extensions use these settings on save, so these settings can work on new and created files.
  • VSCode (User Settings)
    • Configuring EOL here will only apply to new files.
    • You should change the default EOL to LF as a fallback precaution (unless you are working on Windows only environment).
    • These settings are only per user which means they are local and are not shared.
  • VSCode (Workspace settings)
    • Configuring EOL here will only apply to new files.
    • You should change the default EOL to LF as a fallback precaution (unless you are working on Windows only environment).
    • These settings can be commited to a repo and thus can be shared.

Git for Windows - Installer - Questions

Checkout as-is, commit as-is (Git for Windows) (core.autocrlf = false)

Why should I choose this option, here is a simple Pros vs Cons:

  • Pro
    • All modern editors can handle all EOL types and does not need Git to do any conversions.
    • Your code will be exactly the same in the local Git as well as the remote repository.
    • Your code will not get corrupted because of the EOL conversions
    • You can use a mix of files with different EOL.
    • You can submit single files with mixed EOL (currently VSCode does not support mixed EOL).
    • You can submit files with any EOL (CRLF / CR / LF).
    • Can granular control which files have their EOL translated by Git at the repository level using .gitattributes.
    • EOL specified by .editorconfig will be honoured and kept when the files are submitted to the repository.
  • Con
    • Requires the editor and repository to be setup correctly to prevent EOL inconsistencies amongst programmers.

Checkout Windows-style, commit Unix-style line endings (Git for Windows) (core.autocrlf = true)

Why should I choose this option, here is a simple Pros vs Cons:

  • Pro
    • If your files in a project have different EOL, this could ensure compatibility with minimal input from the user.
      • = You should set your development environment up better.
    • Good for people who work across different OS and platforms to ensure the repository always has the correct line endings.
      • = You should set your development environment up better.
  • Con
    • Can cause corruption in your code e.g. binary blob.
    • All EOL will be changed, meaning that if there are mixed EOL, then this difference will be lost whether that be in a single file or files with different EOL.

Bulk Changing EOL

So you already have a load of files with CRLF and now you need them all to be LF before committing them to Git.

  • VSCode
    • Change All End Of Line Sequence
      • Runs the built-in 'Change End Of Line Sequence' on all files of a specified type, leaving them open and unsaved.
    • Auto Convert End Of Line
      • Automatically convert files with configured end-of-line sequence when they are opened.
      • Every time a text files is opened, it converts all the EOL sequences into the specific one from the files.eol configuration, and displays an auto-dismissed notification. If no conversion is needed, or if files.eol is configured to be "auto", this extension does nothing.
  • Windows
  • Linux
    • Converting between Windows and Linux line breaks | Commandline Wizardry 
      sed -i 's/$/\r/' fileLinux.txt
find -type f -exec sed -i 's/$/\r/' '{}' \;
tr -d '\r' < fileWindows.txt > fileLinux.txt
sed -i 's/\r//' fileWindows.txt
    • Dos2unix Command on Linux with Examples - idroot - Learn how to effectively use the 'dos2unix' command on Linux to ensure seamless file compatibility.
    • Dos2unix: The Linux File Conversion Command Explained
      • Ever found yourself grappling with line ending issues when transferring text files between Windows and Unix/Linux systems? You're not alone. You’re not alone. Many developers find themselves in this predicament, but there’s a tool that can help you navigate these choppy waters.
      • In this guide, we’ll walk you through the process of using the dos2unix command in Linux, from the basics to more advanced techniques. We’ll cover everything from simple file conversions to handling multiple files, as well as alternative approaches and troubleshooting common issues.
      • The dos2unix command is a straightforward yet powerful tool in the Linux arsenal. Its primary role is to convert text files from DOS/MAC to Unix format, which is vital when transferring files between different operating systems.
    • Find Out Text File Line Endings - LF or CLRF - ShellHacks
      • How to find out the line endings in a text file and how to convert the Unix/Linux newline characters ("n" or "LF") to DOS/Windows ("rn" or "CRLF").
      • Change Newline Characters 
        ## To convert the newline characters from DOS/Windows to Unix/Linux:
$ dos2unix <filename>

## To convert the newline characters from Unix/Linux to DOS/Windows:
$ unix2dos <filename>
    • Conversion between newline formats - Newline | Wikipedia - Many Linux examples here.
  • Python
  • NodeJS

Links / Research

History of CRLF and LF

Handling Line Conversions articles

  • Configuring Git to handle line endings - GitHub Docs
  • Harmonizing Line Endings Across Windows and WSL | xakpc.info - When using a Git repository across Windows and Windows Subsystem for Linux (WSL), you may encounter unexpected issues with line endings. This article explains why these issues occur and how to resolve them effectively.
  • Guide to line ending handling in Git · GitHub - This guide serves to clear up how Git handles line endings, how to avoid problems with them, how to fix problems if they come up, and some great tools for dealing with line endings in general.
  • Git LF to CRLF: Mastering Line Endings Simply - Discover why git lf will be replaced by crlf and how to adapt your workflow. This concise guide simplifies the transition for smooth version control.
    • Consistent Configuration: Ensure that every team member has set their `core.autocrlf` appropriately for their operating system.
    • Use of .gitattributes: Proper configuration of the `.gitattributes` file can minimize discrepancies; this ensures everyone follows the same rules for line endings.
  • Resolving Git Line Ending Issues Once and For All | TheLinuxCode - In this comprehensive 2500+ word guide, you‘ll gain a deeper understanding of controlling Git line endings plus actionable solutions to banish newline woes.
  • git - How to change line-ending settings - Stack Overflow
    • Global Configuration
      • In Linux/OSX 
        git config --global core.autocrlf input
        This will fix any CRLF to LF when you commit.
      • In Windows 
        git config --global core.autocrlf true
        This will make sure that, when you checkout in windows, all LF will be converted to CRLF.
    • .gitattributes File
      • It is a good idea to keep a .gitattributes file as we don't want to expect everyone in our team to set their own config. This file should be placed in the repository root and, if it exists, git will respect it.
  • * text=auto in .gitattributes file - DEV Community - In this article, we analyse the .gitattributes from the react/.gitattributes. When you are part of a team, you and your colleagues often work on projects across different operating systems and development environments. As a result, file formatting issues, especially related to line endings, can arise.

Pro (Checkout as-is, commit as-is)

  • (.gitattributes)
    • How to configure Git line endings correctly | LabEx (Read this)
      • Master Git line ending configurations for seamless cross-platform development, prevent file conflicts, and ensure consistent code formatting across different operating systems.
      • This is a detail article with relevant diagrams and explores all aspects of this topic.
      • Using .gitattributes for explicit control and set EOL in VSCode to be \n
      • .gitattributes Example 
        ## Specify precise line ending behaviors
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.txt text eol=lf
    • How To: Handle Line Endings with Git | Shane Bart
      • Learn how to handle line endings when using git across various operating system platforms
      • Option 1: ‘core.autocrlf’ git config (legacy approach)
        • 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.
      • Option 2: Using .gitattributes (Recommended)
        • This enables you to capture all required configuration in source control, rather than needing to rely on developers within your team to explicitly configure git.
      • Also, try to stay away from using both these approaches together as it is more than likely to create confusion and lead to issues.
    • .gitattributes Best Practices - Muhammad Rehan Saeed (Read this)
      • Git can actually be configured to automatically handle line endings using a setting called autocrlf. This automatically changes the line endings in files depending on the operating system. However, you shouldn't rely on people having correctly configured Git installations.
      • Covers many aspects of this file and how useful it is.
      • A complete .gitattributes file
      • Only the first line is strictly necessary. It hard codes the line endings for Windows cmd and batch scripts to CRLF and bash scripts to be LF, so that they can be executed via a file share. It's a practice I picked up from the corefx repository.
      • From comments
        • Most of the programming editors these days support working with either line ending, regardless of the platform they run on, and most other tools (compilers etc..) are line-ending-agnostic.
        • I've found I've had more problems caused by git trying to be helpful and converting my line endings for me, than the other way around. So I'd say best practice is to use * -text in the .gitattributes and add .editorconfig that enforces the projects preferred line endings. An added benefit is that you can also specify file encodings in your .editorconfig file.
      • .gitattributes Example 
        ###############################
# Git Line Endings            #
###############################

# Set default behaviour to automatically normalize line endings.
* text=auto

# Force batch scripts to always use CRLF line endings so that if a repo is accessed
# in Windows via a file share from Linux, the scripts will work.
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

# Force bash scripts to always use LF line endings so that if a repo is accessed
# in Unix via a file share from Windows, the scripts will work.
*.sh text eol=lf

###############################
# Git Large File System (LFS) #
###############################

# Archives
*.7z filter=lfs diff=lfs merge=lfs -text
*.br filter=lfs diff=lfs merge=lfs -text
*.gz filter=lfs diff=lfs merge=lfs -text
*.tar filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text

# Documents
*.pdf filter=lfs diff=lfs merge=lfs -text

# Images
*.gif filter=lfs diff=lfs merge=lfs -text
*.ico filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.pdf filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.webp filter=lfs diff=lfs merge=lfs -text

# Fonts
*.woff2 filter=lfs diff=lfs merge=lfs -text

# Other
*.exe filter=lfs diff=lfs merge=lfs -text
    • Git for Windows: Line Endings | Edward Thomson
      • The key to dealing with line endings is to make sure your configuration is committed to the repository, using .gitattributes. 
      • Checkout Windows-style, commit Unix-style line endings: This is why one of the most common symptoms of a line ending configuration problem is seeing “phantom changes”: running git status tells you that you’ve changed a file, but running git diff doesn’t show you any changes.
    • Git Handling Line Endings (CRLF) | git-cookbook
      • This covers both .gitconfig and .gitattributes with good examples
      • CRLF conversion bears a slight chance of corrupting data. When core.autocrlf is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.
      • Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data.
      • core.safecrlf is basically just a way to make sure you don’t irreversably perform CRLF conversion on a binary file.
      • Optionally, you can configure a .gitattributes file to manage how Git reads line endings in a specific repository. When you commit this file to a repository, it overrides the core.autocrlf setting for all repository contributors. This ensures consistent behavior for all users, regardless of their Git settings and environment.
      • Some good examples.
      • core.eol - Sets the line ending type to use in the working directory for files that are marked as text. Alternatives are lf, crlf and native, which uses the platform’s native line ending. The default value is native. 
        git config core.eol lf      # LF
git config core.eol crlf    # CRLF
git config core.eol native  # platform (default)
      • .gitattibutes example 
        # Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary
  • (.gitattributes) (.editorconfig)
    • CRLF vs. LF: Normalizing Line Endings in Git | Aleksandr Hovhannisyan (Read this)
      • Line endings can differ from one OS to another. Learn the history behind CRLF and LF line endings and how to enforce line endings in Git.
        • The typical advice is to configure your local Git to handle line ending conversions for you. For the sake of comprehensiveness, we’ll look at how that can be done in this article, but it isn’t ideal if you’re on a large team of developers.
          • The core.autocrlf setting isn’t the ideal approach for configuring line endings in a project.
        • A better solution is to add a .gitattributes file to your repo so you can enforce line endings consistently in your codebase regardless of what operating systems your developers are using.
        • A .gitattributes file is technically all that you need to enforce the line endings in the remote copy of your code. However, as we just saw, you may still see CRLF line endings on Windows locally because .gitattributes doesn’t tell Git to change the working copies of your files. Fortunately, we can take things a step further with an .editorconfig file; this is an editor-agnostic project that aims to create a standardized format for customizing the behavior of any given text editor. Lots of text editors (including VS Code) support and automatically read this file if it’s present.
        • Gives the history of these control characters and the specific differences.
        • Configuring Line Endings in Git with core.autocrlf
          • By default, core.autocrlf is set to false on a fresh install of Git, meaning Git won’t perform any line ending normalization. Instead, Git will defer to the core.eol setting to decide what line endings should be used; core.eol defaults to native, which means it depends on the OS you’re using. That’s not ideal because it means that CRLF may make its way into your code base from Windows devs.
          • Both of these options enable automatic line ending normalization for text files, with one minor difference: core.autocrlf=true converts files to CRLF on checkout from the repo to the working tree, while core.autocrlf=input leaves the working tree untouched.
          • For this reason, core.autocrlf=true tends to be recommended setting for Windows developers since it guarantees LF in the remote copy of your code while allowing you to use CRLF in your working tree for full compatibility with Windows editors and file formats.
        • A Simple .gitattributes Config
          • The following .gitattributes config normalizes line endings to LF for all text files checked into your repo while leaving local line endings untouched in the working tree:
          • More specifically, the text=auto option tells Git to only normalize line endings to LF for text files while leaving binary files (images, fonts, etc.) untouched. This distinction is important—we don’t want to corrupt binary files by modifying their line endings.
          • After committing the .gitattributes file, your changes won’t take effect immediately for files checked into Git prior to the addition of .gitattributes. To force an update, you can use the following command since Git 2.16:
        • Many Git commands are shown and explained.
        • Summary
          • That was a lot to take in, but hopefully you now have a better understanding of the whole CRLF vs. LF debate and why this causes so many problems for teams that use a mixture of Windows and other operating systems. Whereas Windows follows the original convention of a carriage return plus a line feed (CRLF) for line endings, operating systems like Linux and Mac use only the line feed (LF) character.
          • The history of these two control characters dates back to the era of the typewriter. While this tends to cause problems with software like Git, you can specify settings at the repo level with a .gitattributes file to normalize your line endings regardless of what operating systems your developers are using.
          • You can also optionally add an .editorconfig file to ensure that new files are always created with LF line endings, even on Windows.
        • Comments
          • Using a .gitattributes file is indeed the best practice, but if you are working on a personal repository, it shouldn’t matter. In fact, autocrlf=true wouldn’t cause any problems even if you were working with other Linux/Mac developers since the remote code would always have LF line endings anyway. The main reason why autocrlf is not useful is because you have to keep setting it up every time you get a new Windows machine (since line ending normalization is turned off by default in Git). If you forget to set it up, you’ll re-introduce CRLF into the remote code. From my article:
    • Normalizing Line Endings in Git: CRLF vs. LF - MyBlueLinux.com
      • If you’ve ever worked on a project where developers use different operating systems, you know that line endings can be a peculiar source of frustration.
      • The typical advice is to configure your local Git to handle line ending conversions for you. For the sake of comprehensiveness, we’ll look at how that can be done in this article, but it isn’t ideal if you’re on a large team of developers.
      • A better solution is to add a .gitattributes file to your repo so you can enforce line endings consistently in your codebase regardless of what operating systems your developers are using.
      • We’ll briefly review the history behind line endings on Windows and Unix so we can understand why this issue exists in the first place.
      • By default, core.autocrlf is set to false on a fresh install of Git, meaning Git won’t perform any line ending normalization. Instead, Git will defer to the core.eol setting to decide what line endings should be used; core.eol defaults to native, which means it depends on the OS you’re using. That’s not ideal because it means that CRLF may make its way into your code base from Windows devs.
      • That leaves us with two options if we decide to configure Git locally: core.autocrlf=true and core.autocrlf=input. The line endings for these options are summarized below.
        • core.autocrlf=true / LF / CRLF
        • core.autocrlf=input / LF / original (usually LF, or CRLF if you're viewing a file you created on Windows)
        • Both of these options enable automatic line ending normalization for text files, with one minor difference: core.autocrlf=true converts files to CRLF on checkout from the repo to the working tree, while core.autocrlf=input leaves the working tree untouched.
      • core.autocrlf=true / * text=auto eol=crlf / LF / CRLF
      • core.autocrlf=input / * text=auto / LF / original (LF or CRLF)
  • (.editorconfig)
    • Using the .editorconfig in VS2019 and VSCode | ASP.NET Hacker 
      • In the backend developer team of the YOO we are currently discussing coding style guidelines and ways to enforce them. Since we are developer with different mindsets and backgrounds, we need to find a way to enforce the rules in a way that works in different editors too.
      • The .editorconfig is a text file that overrides the settings of the editor of your choice.
      • Almost every code editor has settings to style the code in a way you like, or the way your team likes. If this editor supports the .editorconfig you are able to override this settings with a simple text file that usually is checked in with your source code and available for all developers who work on those sources.
      • If VS2019 finds an .editorconfig it will use it immediately and it will check your code on every code change.
    • Windows Git Users: Don't Convert Line Endings - With conversion enabled, the checked-out files are in a different state than their source repository. This can lead to strange errors where build artifacts or files transferred to other systems are subtly different than those generated from the unmodified source.

Git and Repository EOL Configuration

  • .gitconfig (Global settings)
  • .gitattributes
    • Configuring Git to handle line endings - GitHub Docs - To avoid problems in your diffs, you can configure Git to properly handle line endings.
    • gitattributes | Documentation | git-scm.com - List the relevant switches and values.
    • text - gitattributes | Documentation | git-scm.co
      • This attribute marks the path as a text file, which enables end-of-line conversion: When a matching file is added to the index, the file’s line endings are normalized to LF in the index. Conversely, when the file is copied from the index to the working directory, its line endings may be converted from LF to CRLF depending on the eol attribute, the Git config, and the platform (see explanation of eol below).
    • 8.2 Customizing Git - Git Attributes | Documentation | git-scm.com
      • Using attributes, you can do things like specify separate merge strategies for individual files or directories in your project, tell Git how to diff non-text files, or have Git filter content before you check it into or out of Git.
      • In this section, you’ll learn about some of the attributes you can set on your paths in your Git project and see a few examples of using this feature in practice.
    • Git .gitattributes | W3 Schools
      • The .gitattributes file is a special file that tells Git how to handle specific files in your repository.
      • It controls things like line endings, file types, merge behavior, custom diff tools, and more.
      • Everyone on your team gets the same settings because this file is versioned with your project.
      • Put .gitattributes in subfolders for rules that only apply there.
    • gittattributes force all text files to lf - Bing Search
      • To ensure all text files in your Git repository use LF (Line Feed) as the line-ending format, you can configure a .gitattributes file. Here's how you can do it:
      • Steps:
        • Create or edit a .gitattributes file in the root of your repository.
        • Add the following line to enforce LF for all text files: 
          * text=auto eol=lf
      • Explanation:
        • *: Matches all files in the repository.
        • text=auto: Tells Git to automatically detect text files.
        • eol=lf: Ensures that line endings are normalized to LF when files are checked out.
      • Additional Notes:
        • If you already have files with CRLF endings in your repository, you may need to normalize them. Run the following commands after setting up .gitattributes: 
          git add --renormalize .
git commit -m "Normalize line endings to LF"
        • This ensures consistency across different operating systems and prevents issues caused by mismatched line endings.
    • Why does .gitattributes not override core.autocrlf configuration on Linux? - Stack Overflow
      • So if you want to use attributes to control the line ending you get in the work tree, you need to set the eol attribute (not merely the text attributes).
      • So, to answer your question: no, what you've described is not a bug.
  • .editorconfig

VSCode EOL Configuration

 

Read 182 times Last modified on Monday, 26 May 2025 16:31
Published in Programming
back to top