Problems with autoCRLF?

Problems with autoCRLF?

[Raimund Bauer]

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 ;-)

-- 
best regards

  Ray

Re: Problems with autoCRLF?

[Robin Rosenberg]

fredag 09 mars 2007 19:15 skrev Raimund Bauer:
> 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

Re: Problems with autoCRLF?

[Linus Torvalds]

On Fri, 9 Mar 2007, Robin Rosenberg wrote:

> fredag 09 mars 2007 19:15 skrev Raimund Bauer:
> > 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

Re: Problems with autoCRLF?

[Junio C Hamano]

Raimund Bauer <ray007@gmx.net> writes:

> 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.

Re: Problems with autoCRLF?

[Raimund Bauer]

On Fri, 2007-03-09 at 17:24 -0800, Junio C Hamano wrote:

> 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(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5408dd6..7864ea3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -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
-- 
1.5.0.3.942.g299f

-- 
best regards

  Ray