On Jan 7, 2008, at 11:06 PM, Junio C Hamano wrote:
Steffen Prohaska <[EMAIL PROTECTED]> writes:
I believe the main question is which type of projects we would like
to support by our default. For real cross-platform projects that
will
be checked out on Windows and Unix we should choose
"core.autocrlf true" as our default. But if our default are native
Windows projects that will never be checked out on Unix, then we
should not set core.autocrlf by default.
If the primary target is native Windows projects that wants CRLF
in the work tree, you could still set core.autocrlf. Your
checkouts will be with CRLF. And someday perhaps somebody may
offer porting that to UNIX and his checkout will be without CR.
So wouldn't the categorization be more like this?
- "real cross-platform" would want core.autocrlf = true;
- "native Windows" can work either way;
But core.autocrlf = true has a slight danger of data corruption.
AFAIK, git's binary detection checks the first "few" bytes (with
few = 8000). This may be sufficient in most case, but I already
met a file that was wrongly classified. (A File format that
starts with a large ASCII header and has chunks of binary data
attached later.)
- "originated from UNIX" would be helped with core.autocrlf = true;
I'd say "could be helped". For the msysgit development, for
example, we do _not_ want to have core.autocrlf = true but
prefer to preserve the Unix line ending even when working on
Windows. We have only few Windows-specific files that are
committed with CRLF. We _know_ the problem and we explicitly
handle it.
I believe, best would be if a line ending policy could be
configured for a project. Then, the decision could be made once
for the project and should be enforced on all clones. But
currently git has no concept for this.
A sound policy for "real cross-platform" is that CRLF must never
enter the repository unless git detects a file as binary, or a
file is explicitly listed in .gitattributes. It doesn't really
matter if Windows users check out files with CRLF or LF. It only
matters that they'll never commit a file with CRLF. Note, the
same is true for Unix users. People could send code by email or
copy source files from Windows to Unix machines. Then, CRLF
would enter the repo on Unix. So the least that should be set
for this type of projects on any OS is core.autocrlf = input.
On Windows, core.autocrlf = true is probably more natural.
I like Linus' idea of "warn" or Gregory's "fail".
Would "warn/fail" be the default on Unix, too? Then Unix users
would also be forced to make an explicit choice. Maybe some day
they want to check out their project on Windows and they should
be prepared now. For typical files, the warning (or error) would
never trigger. But maybe one day they copy a file from a Windows
machine and forget to run dos2unix. In this case, git would warn
them unless they set "core.autocrlf = false".
I'm asking the last question because every Unix developer should
think about the option, too. Neither Unix or Windows are causing
the problem alone. It's the combination in a cross-platform
project. Git could ensure that any repository is in principal
prepared for cross-platform, unless explicitly told not to do so.
So, would you, as Linux developers, like to have (or accept)
"warn/fail" as your default?
This would make things easy for the msysgit project: No Windows
specific configuration; just official git.
Steffen
