git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Torsten Bögershausen'" <tboegi@web.de>,
	"'Robert Dailey'" <rcdailey.lists@gmail.com>
Cc: <jrnieder@gmail.com>, "'Git'" <git@vger.kernel.org>
Subject: RE: Automatic core.autocrlf?
Date: Thu, 30 Aug 2018 15:10:23 -0400	[thread overview]
Message-ID: <005c01d44095$1d5288c0$57f79a40$@nexbridge.com> (raw)
In-Reply-To: <20180830185648.GA10427@tor.lan>

On August 30, 2018 2:57 PM, Torsten Bögershausen wrote:
> On Thu, Aug 30, 2018 at 09:57:52AM -0500, Robert Dailey wrote:
> > On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder <jrnieder@gmail.com>
> wrote:
> > >
> > > Hi,
> > >
> > > Robert Dailey wrote:
> > >
> > > > Is there an 'auto' setting for the 'core.autocrlf' config? Reason
> > > > I ask is, I want that setting to be 'input' on linux but 'true' on
> > > > Windows.
> > >
> > > Others are exploring your question about the configuration language,
> > > but I want to emphasize some other ramifications.
> > >
> > > Why do we still have 'core.autocrlf'?  Do 'core.eol' and related
> > > settings take care of that need, or is autocrlf still needed?  If
> > > core.eol etc do not take care of this need, what should we do to get
> > > them to?
> > >
> > > Thanks, after having run into a few too many autocrlf-related
> > > messes, Jonathan
> >
> > From my perspective, the confusion is due to the evolution of the
> > feature. There's multiple ways to control EOL handling but most of it
> > is legacy/backward compatibility, I think. core.autocrlf is a
> > fall-back for repos that do not have a .gitattributes. Because
> > .gitattributes is optional by design, I'm not sure if getting rid of
> > the config options is a good idea.
> 
> Good summary. My original plan was to try to "make obsolete"/retire and
> phase out core.autocrlf completely.
> However, since e.g. egit/jgit uses it
> (they don't have support for .gitattributes at all) I am not sure if this
is a good
> idea either. Opinions are welcome.
> 
> 
> > But your point did make me think
> > about how `core.autocrlf = true` should probably be a system config
> > default for the Git for Windows project. The default for that value
> > should be platform-defined. That would make it automatically work the
> > way I want, and might solve a lot of the issues where people are
> > committing CRLF into repositories on Windows.
> 
> Unless I am wrong, that had been the default a long time ago:
> Git for Windows (at that time msysgit) had core.autocrlf=true by default.
> While this is a good choice for many repos, some people prefer
> core.autocrlf=input.
> Others just commit files for Windows-based repos with CRLF, and the
> advantage is, that "git diff" doesn't show "^M" somewhere.
> 
> I allways encourage people to set up a .gitattributes file.
> Does anybody thinks that we can make core.autocrlf obsolete ?

The last time I checked, EGit does not set this by default. ECLIPSE Oxygen
3A/EGit-JGit 5.0.1, when running on Windows, creates core.filemode=false,
core.logallrefupdates=true, repositoryformatversion=0, symlinks=false. Some
SourceTree versions that predate the newer SourceTreeApp are somewhat stuck
on older embedded versions of git, but that may not be relevant. Personally,
I would seriously like to drop core.autocrlf and just have everyone on LF
EOL characters. I get frequently burnt by this despite knowing better.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.




  reply	other threads:[~2018-08-30 19:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 14:10 Automatic core.autocrlf? Robert Dailey
2018-08-27 15:35 ` Torsten Bögershausen
2018-08-27 15:52   ` Duy Nguyen
2018-08-27 17:29     ` Robert Dailey
2018-08-27 17:32     ` Andrei Rybak
2018-08-27 18:22       ` Andrei Rybak
2018-08-28  0:14       ` brian m. carlson
2018-08-30 14:53       ` Robert Dailey
2018-08-30  4:54 ` Jonathan Nieder
2018-08-30 14:57   ` Robert Dailey
2018-08-30 18:56     ` Torsten Bögershausen
2018-08-30 19:10       ` Randall S. Becker [this message]
2018-08-31  3:29       ` Jonathan Nieder
2018-08-31 11:57         ` Randall S. Becker
2018-08-31 13:17           ` Torsten Bögershausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='005c01d44095$1d5288c0$57f79a40$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=rcdailey.lists@gmail.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).