<div dir="ltr"><div dir="ltr">On Tue, 10 Aug 2021 at 13:35, MyDeveloper Day <<a href="mailto:mydeveloperday@gmail.com">mydeveloperday@gmail.com</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 dir="ltr"><div>FWIW, I run a multi million line project, we run the bleeding edge, last released version, each release of Clang-Format I have maybe 10-20 files to change. If I left it 5 or so releases I'm sure the impact would seem greater.</div></div></blockquote><div><br></div><div>That's not the only problem.</div><div><br></div><div>If people have different versions of clang-format installed, and you have format as part of the workflow, committing will often include rewrites of the same things.</div><div><br></div><div>In our case, if our formatting doesn't match the CI formatting the PR is rejected. Even just running on the changed lines, you get different results.</div><div><br></div><div>The only solution is to force people to install clang-format-X locally.</div><div><br></div><div>You can say "clang-format wasn't designed for that", but that's what it's used for in many places and its user base is now massive.</div><div><br></div><div>You wanted to gather opinions of what clang-format could/should do, well, those are common use cases.</div><div><br></div><div>Adding more breaking changes without safety pins will make usage reduce, not increase. </div><div><br></div><div>IMHO, if you want more people to use you need to increase safety first, then add breaking changes with visible warnings (naming, flags, comments, whatever), and make sure breaking changes are not on by default.</div><div><br></div><div>For example, if clang-format starts breaking code without notice, we'll have to stick to -9 forever, or remove it as a dependency for PRs altogether.</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>