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