[clang] [clang-tools-extra] [flang] [lldb] [llvm] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

[Martin Storsjö via llvm-commits]

mstorsjo wrote:

> So if I've read that correctly, `core.autocrlf=false` is a red herring and you should really set `core.eol=lf` if you want git to use `lf` on windows.

That perhaps may be the case, but all common docs and all common practices around this revolve around setting `core.autocrlf`, not setting `core.eol`. Before this discussion, I have never seen a guide recommending setting `core.eol`.

While so far, all docs related to this say that it is `core.autocrlf` one should set: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.2/clang/www/get_started.html#L151-L154 and https://github.com/llvm/llvm-project/blob/llvmorg-19.1.2/llvm/docs/GettingStarted.rst?plain=1#L37.

> > Would we get there by setting the wildcard rule in .gitattrubtes to * text eof=lf, or something along those lines?
> 
> This patch is about respecting local config, which is the exact opposite of that suggestion. It would be a way to solve the line-ending issue by fiat, not by co-operation, so I'm against it on principle. To be clear I very much don't like CRLF, but I also very much don't like it when someone forces me to use wrong-handed tools. Windows users would be forced to use wrong handed tools if we force line-endings one way or another

But if every single Windows developer involved here say that they want LF, and they don't want any ambiguity about it? Is it more important to give hypothetical users the choice to pick what they like, at the cost of every single current developer who do not want that, and breaking every established setup routine?

https://github.com/llvm/llvm-project/pull/86318