Contents contributed and discussions participated by Daniel Jomphe - learning-git

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

Cancel
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".
...

Cancel
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.
...

Cancel
...3 more annotations...
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.)
...

Cancel
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.
...

Cancel
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;
...

Cancel

Daniel Jomphe on 02 Oct 08

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 ha

<div class="cArrow"> </div><div class="cContentInner">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 ha</div>

...

Cancel