Re: [boost] [git] Line endings in bootstrap.bat on Windows

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:

> AMDG
>
> 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
line endings.

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