Manage text file EOL with WSL to access git working tree clone form windows

readme.adoc

Introduction

Table of Contents

• Editor
  • notepad
  • vscode
  • Delphi IDE
  • vi or nano
• GIT
• Using WSL to access git working tree clone form windows
• Best Practice

This is a dicussion to manage EOL (end of line) of text file store in GIT repository.

There are 2 EOL style:

• LF (0x0A): Linux Style - Utilize in Linux text files and Git Repository

• CRLF (0x0Dh 0x0A): Windows Style - Utilize in Windows text files.

Editor

Basically, most windows editor work with any EOL styled text files seamlessly. However, new files created in Windows will use CRLF by default.

In our working environment, these are common used editors:

notepad

Latest windows 10 notepad support open and edit files of both Windows and Linux style. But it don’t have easy way to switch between EOL style at runtime.

vscode

vscode can switch EOL style at runtime.

Delphi IDE

Delphi IDE do have Line Ending settings. The default behavior is similar to notepad.

vi or nano

vi or nano in Linux works with LF natively. vi show ^M at EOL for CRLF text file.

GIT

Git offer auto CRLF conversion. Your git environment may already have set autocrlf to True`, check with:

git config core.autocrlf

This is the command to set:

git config --global core.autocrlf true

With autocrlf=true:

• git store auto convert text files from CRLF to LF before push into commit.

• git convert LF to CRLF after checkout from commit.

These behavior work nicely for git repository storing Delphi project or any Windows based project.

autocrlf=true setting is global. Any projects clone from git repository will perform the EOL style conversion.

This behavior works in all mix environment except one situation discussed in next topic.

Using WSL to access git working tree clone form windows

Let’s look at an example, clone a Linux based repository in windows file system:

git clone https://github.com/eStreamSoftware/scripts

and execute the script file in WSL. It will prompt:

-bash: ./run.sh: /bin/bash^M: bad interpreter: No such file or directory.

This is due to git in Windows convert from LF to CRLF. Linux shell won’t normalize the script file when executing. Using vi shows all EOL has ending ^M.

A quick solution is using --config core.autocrlf=true when cloning a linux based repository in windows:

git clone --config core.autocrlf=true https://github.com/eStreamSoftware/scripts

However, most git cloning operation using GUI don’t support autocrlf. And user must know the EOL style prior to clone the repository.

Best Practice

I guess linux based project is in dominated position among Git repository. Chances to work with Linux based project is relatively high compare to Window based projects.

In Linux environment, all git operation and working tree will work with Linux style.

In windows environmen, I setup my git working environment conform to Linux based EOL style:

git config --global core.autocrlf false

Now, all files checkout from the repository use Linux style EOL (LF). In Windows environment, it is still prefer to work with text file stored as CRLF EOL.

A good news is Git do support per repository EOL via .gitattributes

For windows based repository, create a .gitattributes file:

• text=auto

A git working tree forked from the repository in Windows will convert text files into CRLF. Commits for text files pushed into repository store with LF as usual.

This practice should allow windows based git repository to work seamlessly in mixed environment.