Let us imagine we have a git repository containing a shell script (aptly named list), and a Dockerfile. Here are the contents of list:

If you are playing along, then be sure to make list an executable with chmod.

Here is our (rather simplistic, and admittedly pointless) Dockerfile.

Great! Now we can build a docker image (with the tag demo) like so:

If all goes well, you should see something like this:

We can see the contents of the tmp directory listed as part of building the image.

Now, for grins and giggles, use your favorite text editor to convert the line-endings in list to be CRLF. In Sublime Text 3 this option is available under View → Line Endings. In VS Code there is a toggle at the bottom right hand of the editor that allows you to switch from LF to CRLF. Be sure to save the file!

Now, let us attempt to build our Docker image again. Here is the resulting output:

One might not be surprised that this did not work — we are introducing invalid line delimiters in a shell script. However the error is a tad baffling. We can attempt to debug this by commenting out the RUN list instruction in our Dockerfile, building the image again, and then seeing if the file was indeed copied over.

The file exists, however, both the RUN instruction, as well as our attempt to manually execute it via docker run fail.

So what has this got to do with git?

It turns out, that if this code was checked into a git repository, and someone on Windows cloned the codebase, by default Git will attempt to convert the line-endings into CRLF! In almost all cases this is what you want. Except when you don’t :)

You can easily test by initializing a git repository (assuming you are playing along) in the current directory, and then forcing git to checkout all files with CRLF like so:

Notice that git status reports a clean working directory. Here lies the part where you are left scratching your head when you attempt to debug this problem. It’s the same repository, with the same code-base, and git reports that nothing has been touched!

If you wish to preserve CRLF on Windows, but maintain LF across your text files on OSX/Linux, as well as in git repository, then the .gitattributes file is your friend. This answer on Stack Overflow provides a rather comprehensive treatment on the subject.

However, we must realize that our situation is a tad different — in that, we not only want git to normalize line-endings in the repository, but keep those line-endings in the working directory. In other words, we have to inform git to keep LF both when checking in, and checking out files. The solution is to explicitly set the line-ending normalization to be LF like so:

As described on the .gitattributes man page this will ensure that ALL files have LF in the working directory.

Admittedly our example is rather trivial. In a real project you will have other kinds of files where you want native line-endings in the working directory. In that case, you will have to fine tune the .gitattributes file — you will have to explicitly set the eol attribute for specific files, or using wild-cards, while ensuring that all files have LF when checked in, but upon checkout default to the native line-endings.

Let’s say our project had a few more files — some shell scripts, a bat file, some Java source code, and the aforementioned Dockerfile and list file. You might have a .gitattributes file that looks like this:

We should note that the .gitattributes, much like .gitignore in parsed top-to-bottom. Effectively, patterns at a later line could override those before them. With that in mind, it makes sense (in this case) to have the default at the bottom.

Hope this helps!