<div dir="ltr"><div>I use almost exclusively 4 text editors (for some meaning of "editor") in my usual workflow: Sublime Text (for tests), and Visual Studio 2017 (for basically everything else). The third one is Beyond Compare which I use for diffs, and often make minor edits in there prior to commit. Finally, I use the p4merge tool for resolving merge conflicts. On further investigation, it looks like the last of these is the culprit for messing up my line endings (when I save the merge resolution, it saves with Windows line endings), but it has an explicit setting I can change to use LF only endings, so I have fixed this. Hopefully this should prevent me messing up existing files from now on. It doesn't solve the new file issue though, nor does it solve the issue for new people to the project, since it is an obvious counter example to the "all reasonable text editors do the right thing" comment.<br></div><div><br></div><div>I do use dos2unix, but only for generating new patches for uploading to Phabricator. I did experiment with it once when I thought something looked fishy with the line endings in the code I was looking at, but it seemed to touch my whole file. Probably it was in a bad state already though, and I just hadn't realised.<br></div><div><br></div><div>I do think fixing .gitattributes sounds like the best solution, and I certainly would prefer input be the specified preference (I might well change my settings to do that, to solve things for my own workflow), as this solves the new file issue. I note also that git warns if your line endings would be changed automatically when you add a file. I'd propose a note to add to the documentation as a possible compromise, or possibly a pair of options, listing the caveats of each, but I can't think of a concise coherent way of saying it. Suggestions welcome!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 16 Jan 2020 at 18:38, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Jan 16, 2020 at 9:36 AM Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div>
<p class="MsoNormal">I’m inclined to think the <a href="http://llvm.org" target="_blank">llvm.org</a> docs should say to use “input” on Windows, we’ve been happy with that in the Sony repo as James mentioned.<br></p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">But I’d also like to hear from a Windows user from outside Sony first.</p></div></div></blockquote><div><br></div><div>I also think we should recommend `input`, if it does what I think it does: convert from CRLF to LF, and never back.</div><div><br></div><div>This can break a few cases:</div><div>- adding binary files for a test that you forgot to mark binary</div><div>- adding CRLF text files for a test that you forgot to mark binary</div><div><br></div><div>These seem like more common exceptions than adding a new source file, which are often mistakenly committed with CRLF. Any screwups, reverts, and bot breakages from that seem less costly than accidentally adding line ending changes, which live forever as a tax on `git annotate`.</div></div></div>
</blockquote></div>