I have a git repository hosted on github. Many of the files were initially developed on Windows, and I wasn't too careful about line endings. When I performed the initial commit, I also didn't have any git configuration in place to enforce correct line endings. The upshot is that I have a number of files with CRLF line endings in my github repository.
I'm now developing partially on Linux, and I'd like to clean up the line endings. How can I ensure the files are stored correctly with LF on github, and have LF in my working copy?
I've set up a .gitattributes
file containing text eol=LF
; is that correct? With that committed and pushed, can I just rm
my local repo and re-clone from github to get the desired effect?
Best Answer
Without a bit of information about what files are in your repository (pure source code, images, executables, ...), it's a bit hard to answer the question :)
Beside this, I'll consider that you're willing to default to LF as line endings in your working directory because you're willing to make sure that text files have LF line endings in your .git repository wether you work on Windows or Linux. Indeed better safe than sorry....
However, there's a better alternative: Benefit from LF line endings in your Linux workdir, CRLF line endings in your Windows workdir AND LF line endings in your repository.
As you're partially working on Linux and Windows, make sure
core.eol
is set tonative
andcore.autocrlf
is set totrue
.Then, replace the content of your
.gitattributes
file with the followingThis will let Git handle the automagic line endings conversion for you, on commits and checkouts. Binary files won't be altered, files detected as being text files will see the line endings converted on the fly.
However, as you know the content of your repository, you may give Git a hand and help him detect text files from binary files.
Provided you work on a C based image processing project, replace the content of your
.gitattributes
file with the followingThis will make sure files which extension is c, h, or txt will be stored with LF line endings in your repo and will have native line endings in the working directory. Jpeg files won't be touched. All of the others will be benefit from the same automagic filtering as seen above.
In order to get a get a deeper understanding of the inner details of all this, I'd suggest you to dive into this very good post "Mind the end of your line" from Tim Clem, a Githubber.
As a real world example, you can also peek at this commit where those changes to a
.gitattributes
file are demonstrated.UPDATE to the answer considering the following comment
Makes sense. Thanks for the clarification. In this specific context, the
.gitattributes
file by itself won't be enough.Run the following commands against your repository
As your repository is shared between your Linux and Windows environment, this will update the local config file for both environment.
core.eol
will make sure text files bear LF line endings on checkouts.core.autocrlf
will ensure potential CRLF in text files (resulting from a copy/paste operation for instance) will be converted to LF in your repository.Optionally, you can help Git distinguish what is a text file by creating a
.gitattributes
file containing something similar to the following:If you decided to create a
.gitattributes
file, commit it.Lastly, ensure
git status
mentions "nothing to commit (working directory clean)", then perform the following operationThis will recreate your files in your working directory, taking into account your config changes and the
.gitattributes
file and replacing any potential overlooked CRLF in your text files.Once this is done, every text file in your working directory WILL bear LF line endings and
git status
should still consider the workdir as clean.