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
Robin RosenbergRe: Problems with autoCRLF?
fredag 09 mars 2007 19:15 skrev Raimund Bauer:
Show 6 quoted 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
Linus TorvaldsRe: Problems with autoCRLF?
On Fri, 9 Mar 2007, Robin Rosenberg wrote:
Show 10 quoted lines
> 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
Junio C HamanoRe: Problems with autoCRLF?
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?
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