Skip to contentSkip to conversation

Problems with autoCRLF?

DISCUSSION Raimund Bauer 4 participants 5 messages Jun 15, 2016 Documentation

lore
Share & tools
lore
#0 lore raw

Is it really intended that with a setting core.autoCRLF=true textfiles are checked out with crlf-lineendings on linux-boxes?

I found out because the git-compilation broke ...

Now using core.autocrlf=input ;-)

Signature · 3 lines
best regards

  Ray
#1 lore raw

fredag 09 mars 2007 19:15 skrev Raimund Bauer:

Quoted 6 lines

Is it really intended that with a setting core.autoCRLF=true textfiles are checked out with crlf-lineendings on linux-boxes?

I found out because the git-compilation broke ...

Now using core.autocrlf=input ;-)

My guess is it's good for testing without having to compromise your computer (or with cygwin).

-- robin

#2 lore raw
Quoted 10 lines · Robin Rosenberg

fredag 09 mars 2007 19:15 skrev Raimund Bauer:

Quoted 6 lines

Is it really intended that with a setting core.autoCRLF=true textfiles are checked out with crlf-lineendings on linux-boxes?

I found out because the git-compilation broke ...

Now using core.autocrlf=input ;-)

My guess is it's good for testing without having to compromise your computer (or with cygwin).

Exactly. I'd much rather have git work consistently across different architectures, so that we can develop and test the CRLF code under UNIX, without having to actually have to use the brain damage that is Windows.

So yes, don't set "core.autocrlf=true" under UNIX. It will "work", but it will work exactly in the sense of "you can test what we'd do under Windows" ;)

Linus

#3 lore raw
In reply to Raimund Bauer
Quoted 2 lines · Raimund Bauer

Is it really intended that with a setting core.autoCRLF=true textfiles are checked out with crlf-lineendings on linux-boxes?

Yes. The implicit assumption with any setting to core.autoCRLF is that you want to keep the git objects free of CRLF line endings.

- core.autoCRLF 'true' means that your tools that handle text files would be upset findign LF line endings, and they will leave text in CRLF line endings. Checking out from git creates working tree files while adding CR before LF as needed, and checking in from working tree files to git strips CR before LF as needed.

- core.autoCRLF 'input' means that your tools do not mind handling text files in LF line endings and they will leave text in CRLF line endings, so checking out from git creates working tree files by just giving what is stored in the repository, and checking in from working tree files to git strips CR before LF as needed.

So on sane platforms, you do not want to set that variable, unless you are helping to test and improve that feature.

#4 lore raw
Quoted 2 lines · Junio C Hamano

So on sane platforms, you do not want to set that variable, unless you are helping to test and improve that feature.

In that case we should document it as well. Having the information in the Releasenotes is nice, but having it in the git-config manpage too may be better, text taken straight from the Releasenotes for git 1.5.1.

---
 Documentation/config.txt |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)
Documentation/config.txt +11 -0
index 5408dd6..7864ea3 100644
@@ -137,6 +137,17 @@ Can be overridden by the 'GIT_PROXY_COMMAND' environment variable
 (which always applies universally, without the special "for"
 handling).
 
+core.autocrlf::
+    When set to 'true', makes git to convert CRLF at the end of lines
+    in text files to LF when reading from the filesystem, and convert
+    in reverse when writing to the filesystem.  The variable can be
+    set to 'input', in which case the conversion happens only while
+    reading from the filesystem but files are written out with LF at
+    the end of lines.  Currently, which paths to consider 'text'
+    (i.e. be subjected to the autocrlf mechanism) is decided purely
+    based on the contents, but the plan is to allow users to
+    explicitly override this heuristic based on paths.
+
 core.ignoreStat::
 	The working copy files are assumed to stay unchanged until you
 	mark them otherwise manually - Git will not detect the file changes
Signature · 6 lines
1.5.0.3.942.g299f

-- 
best regards

  Ray