Subject: Re: [boost] [git] Line endings in bootstrap.bat on Windows
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-11-27 14:01:00
Steven Watanabe <watanabesj_at_[hidden]> writes:
> On 11/27/2013 09:31 AM, Dave Abrahams wrote:
>>> There are really two options:
>>> a) Correctly preserve svn:eol-style, however git represents it,
>> Git doesn't represent it.
>>> so that the files produced by a git checkout are always binary
>>> identical to those produced by svn checkout.
>> How things are checked out by Git depends on a user's local settings
>> (e.g. autocrlf), so there is no way we can represent things so that a
>> git checkout is *always* identical to an SVN checkout.
>> (Is the same true of SVN?)
> Do I really have to spell this out explicitly?
Could you make an effort to use a slightly less contemptuous tone?
Obviously I am not smart enough to deduce what you mean without an
explicit spelling-out, or I wouldn't be asking.
> I thought it would be obvious that (assuming
> I understand how this works in git) autocrlf=true,
> would mean that the git checkout should be identical
> to an svn checkout on a platform where the native
> line ending is "\r\n" and aurocrlf=false would
> mean that it corresponds to a platform with "\n"
> line endings.
So your criteria for success are:
* a user with autocrlf=true set, on any platform, sees the same file
contents as an SVN user would on Windows, and
* a user with autocrlf=false set sees the same file contents as an SVN
user would on Linux
I'm not even sure that's achievable. It's my understanding that
autocrlf=true is supposed to "do the right thing" depending on platform,
so a Unix user sees unix line endings and a Windows user sees windows
> I don't really care whether this is decided
> via a configuration option or by platform.
> Any other options that affect file contents
> and have associated metadata in svn, should
> be handled similarly.
I'm sorry, but for me to make changes to the process, I need to hear
things spelled out more precisely than "handled similarly," if for no
other reason than that I need to make sure the rest of the people on the
list understand things the same way you and I do. I would hate to
satisfy some mutual understanding we develop and then find that the rest
of the community disagrees with that choice.
> Anyway, this property needs to be preserved
> (I believe that what I just described is actually
> satisfied), while /also/ satisfying the rule:
> - A fresh git checkout shall not show any
> uncommitted changes.
No matter what your personal settings?