Issue 538 in msysgit: Please make core.autocrlf=false by default

86 views
Skip to first unread message

msy...@googlecode.com

unread,
Oct 27, 2010, 9:05:25 PM10/27/10
to msy...@googlegroups.com
Status: New
Owner: ----

New issue 538 by brett.ryan: Please make core.autocrlf=false by default
http://code.google.com/p/msysgit/issues/detail?id=538

The new recommended default for core.autocrlf setting is to be false,
however the current installer defaults to auto, please change the default
to false.

msy...@googlecode.com

unread,
Oct 28, 2010, 12:56:15 AM10/28/10
to msy...@googlegroups.com

Comment #1 on issue 538 by johannes.schindelin: Please make

I must have missed that recommendation. Besides, we made the default "auto"
as requested by a seasoned Git user; you would have to make a very strong
case to make your desired change desirable.

In addition to that, I wonder whether the default has to be changed when
our installer _already_ lets the user choose what the autocrlf setting
should be.

On the other hand, nothing prevents you from making your own installer with
your preferred value selected by default.

msy...@googlecode.com

unread,
Nov 1, 2010, 6:30:09 AM11/1/10
to msy...@googlegroups.com

Comment #2 on issue 538 by sschuberth: Please make core.autocrlf=false by
default
http://code.google.com/p/msysgit/issues/detail?id=538

@brett.ryan, what do you mean by "recommended default"? Do you mean the
state in effect if autocrlf is not specified at all, is that the "default"?
Or is there some place in the documentation saying that autocrlf=false
should be used whenever possible (I wasn't able to find such a statement on
the "git config" help page)?

As autocrlf is a platform specific thing, I don't even think it makes sense
to recommend a global default. A recommended setting default per OS, yes.
And for Windows, that would be autocrlf=true. We've had way to many issues
with different defaults in corporate Windows environments (you'd be
surprised how many people still use Notepad, which cannot handle Unix line
endings).

If we don't get any new and very convincing arguments, I'll close in the
next few days.

msy...@googlecode.com

unread,
Nov 1, 2010, 8:23:06 AM11/1/10
to msy...@googlegroups.com

Comment #3 on issue 538 by brett.ryan: Please make core.autocrlf=false by
default
http://code.google.com/p/msysgit/issues/detail?id=538

I will agree to close as this is subjective, I was referring to the default
when the setting is omitted. Any form of line ending conversion is known to
cause problems, we have experienced problems with utf-8 text files being
converted.

msy...@googlecode.com

unread,
Nov 1, 2010, 8:27:09 AM11/1/10
to msy...@googlegroups.com
Updates:
Status: WontFix

Comment #4 on issue 538 by sschuberth: Please make core.autocrlf=false by
default
http://code.google.com/p/msysgit/issues/detail?id=538

(No comment was entered for this change.)

msy...@googlecode.com

unread,
Nov 1, 2010, 9:05:41 AM11/1/10
to msy...@googlegroups.com

Comment #5 on issue 538 by kusmabite: Please make core.autocrlf=false by
default
http://code.google.com/p/msysgit/issues/detail?id=538

There's nothing new about core.autocrlf defaulting to "false", it has been
this way from the beginning. Personally, I'd rather see the default set
to "input" on all platforms (together with the current default-option to
set it to "true" in the msysGit installer).

The closest I can find to an "official" recommendation on the core.autocrlf
settings is what the GitHub page on the subject says, and they certainly
recommend keeping it on: http://help.github.com/dealing-with-lineendings/

I do encounter the occasional "helpful advice" on StackOverflow where
people recommend other people to disable core.autocrlf. These seems to
often be based on the incorrect assumption that the core.autocrlf feature
is the culprit when symptoms can be removed (or more likely hidden) by
disabling it.

I'm not saying that the new-line situation in Git is perfect, but disabling
core.autocrlf by default on Windows would certainly be a step in the wrong
direction.

UTF-8 files should be converted without damage, because CR and LF both are
among the first 128 code-points which are backwards compatible with ASCII.
If they are not, then that would be a bug.

There could be issues with UTF-16 files though, but IIUC they should
usually be detected as binary files by Git. There's recently been a topic
about issues with UTF-16 files on the git mailing list, but I don't know
the details.


Reply all
Reply to author
Forward
0 new messages