CODEWITHSUNDEEP
windowsgit
Dave Heq
Dave Heq

Reputation: 364

git autocrlf on Windows doesn't commit with CRLF line endings?

I thought I understood autocrlf but in my git GUIs the default setting is "Checkout Windows-style, commit Unix-style line endings ("core.autocrlf" is set to "true")", but we'd actually like files committed with CRLF as well since the server is Windows as well.

Am I reading this wrong or is this printed wrong? The specific tools we use are Git for Windows, Git Extensions, and Git GUI. I'm not sure what the setting should be at to have CRLF all around.

Upvotes: 1

Views: 705

Answers (1)

Edward Thomson
Edward Thomson

Reputation: 78653

I recommend that you perform CRLF conversion even if you're building Windows software on Windows machines and running Windows servers.

A handful of baked in assumptions to Git itself assume that the line endings of your files in the repository are Unix-style. If you violate this assumption, and do a very reasonable thing like checking in files with CRLF line endings, odd things can happen.

For instance: git diff will create patches with mismatched line endings if you do not do line ending conversion. Here I have a file that was created in a repository without line ending conversion (core.autocrlf = false and I have no .gitattributes). I've made a change to one line, and run git diff:

git bash> git diff
diff --git a/file.txt b/file.txt
index f4606e9..45ec98f 100644
--- a/file.txt
+++ b/file.txt
@@ -3,7 +3,7 @@ with \r\n line endings.
 My git repository is configured
 with `core.autocrlf=false`, and
 I do not have a .gitattributes.
-I'm going to change this line
+I'm going to change THIS line^M
 in this file and see what the
 resultant patch file looks like.
 It's going to be ugly!

And indeed, ugly it is - you can see the trailing ^M (\r) on the new line that was added.

Handling native Windows CRLF line endings has improved over the last several versions of Git, but I would still recommend you follow the line ending best practices, even if you are not interoperating with Unix machines.

It doesn't matter if your server is Windows or not. I'm not even sure which server you meant: the server that is hosting your Git repositories (it doesn't check files out, so it doesn't care at all) or the server that you're publishing to (it will get CRLF by virtue of checking out with the right settings).

However, even if you decide that some of these oddities with line endings are acceptable (and they might be), do not rely on core.autocrlf.

The best practices are not to use core.autocrlf, they're to check in a .gitattributes file. core.autocrlf affects your machine, it doesn't affect the repository. You need all repository users to have consistent line ending settings, whether you decide to do translation (and again, I think that you should) or not. Otherwise, the core.autocrlf settings that the other users chose when they installed Git for Windows will lead to everybody checking in things with different line endings, and you will keep flipping them back and forth as each person edits them, which will truly be terrible.

Upvotes: 1

Related Questions