Group items tagged

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