Re: CRLF problems with Git on Win32

[Junio C Hamano <gitster@pobox.com>]

Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:

	By the way, is it your setting that mangles people's
	e-mail addresses?  If it is, is it possible for you to
	configure it to stop doing that?

> I don't think a solution will be found by declaring one platform
> native (UNIX) and all other platform non-native.  The question to
> answer is how to support cross-platform projects.  A valid
> solution should never corrupt data unless the user explicitly
> told git to do so.

I realize I might have misunderstood your intention.

I did not use the word "native" to mean "native vs second class
citizen".  The "native" in my description should have said "a
platform whose native line ending convention happens to match
what the project chose to use as its canonical blob object
representation".  And on such a platform, there is no need to
worry about accidental corruption because there is no autocrlf
involved.   I could have said "lucky platform" instead of
"native".

I have been assuming that both of us are assuming LF line ending
is what a typical cross-platform project would pick as the
canonical blob object representation.  If you are assuming CRLF
line ending as the canonical blob object representation for
projects originating from Windows, UNIX is not native (or
"lucky") in such a project.  Of course, in such a project,
setting "core.autocrlf = true" is absolutely a wrong thing to do
on Windows.  Perhaps you meant that, and I would agree with you.

In such a project, setting "core.autocrlf = reversed" (which
would convert work tree LF line endings to canonical CRLF when
creating a blob, but we currently do not support it) on UNIX
would become necessary, if you want the resulting mess to work
reasonably without configuration.

As long as "cross-platform" needs to support checkouts on
platforms with different conventions, and if you do not give
explicit marking about the binariness, platforms that are not
"lucky" needs to guess.  The alternative is to check out
verbatim and effectively get it all wrong, from the platform
convention's point of view.

There is no avoiding that.

HOWEVER.

If you mean by "cross platform project" a project that picks LF
line ending as the canonical representation, then you cannot
deny the fact that Windows is not "lucky" and without explicit
marking about the binariness, it needs to guess.  Again, the
alternative is to check out verbatim and get it all wrong.