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

[Martin Storsjö via lldb-commits]

mstorsjo wrote:

> This seems to have broken precommit CI on Windows: https://buildkite.com/llvm-project/github-pull-requests/builds/111165#0192a01b-d3ac-44ad-abff-e53ac4a206ab all of the failures look related to line endings, and I noticed that I got a ton of command line messages of the form:
> 
> ```
> warning: in the working copy of 'clang/include/clang/Basic/Attr.td', LF will be replaced by CRLF the next time Git touches it
> ```

Right, that probably relates to the odd situation where files are checked out in one form, but the git attributes indicate that they should be treated differently. Getting git to rewrite the files on disk to match it is kinda messy actually - the best way I've found today is `git rm -r . && git reset && git checkout .`.

> > Do we really want checkouts to default to having the majority of files with CRLF on Windows? I would expect that most people working on Windows don't really want this (this wasn't the case so far anyway)?
> 
> It certainly came as a surprise to me; my editors handle LF line endings just fine on Windows;

Exactly - people haven't had a problem with _having_ LF newlines so far. The main problem probably has been to set up Git to get it in that form.

I obviously don't mind fixing as many tests as possible to pass with any form of newlines, but having all checkouts of the repo actually have files in identical form, rather than in any fuzzy form, feels like a feature to me.

So keeping the gitattributes, but in a form where it dictates checking out files in LF form (which has required setting `core.autocrlf=false` so far) would IMO be preferrable.

Would we get there by setting the wildcard rule in `.gitattrubtes` to `* text eof=lf`, or something along those lines?

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