|
From: Mark W. <ma...@kl...> - 2023-04-20 20:02:59
|
Hi, On Tue, Apr 18, 2023 at 03:05:28PM +1000, Nicholas Nethercote wrote: > On Tue, 18 Apr 2023 at 13:41, Eyal Soha <eya...@gm...> wrote: > > > The problem with doing this is that it really messes with the git blame, > > introducing a lot of changes! > > That's always the first objection that is raised. Turns out there's a good > solution > <https://medium.com/codex/how-to-introduce-a-code-formatter-without-messing-up-git-history-4a16bd074c10> > . (Note that article requires javascript to turn on, or you won't be able to read more than the first paragraph.) Sure you can work around it, but I don't think that is a great solution. It requires everyone to make some local changes. > > If you do this, you should probably add some sort of formatting check to a > > CI process somewhere, otherwise your work will get stale and you'll just be > > doing the clang-format again in a year from now. > > > > Yes. > > > Good luck to you trying to get everyone to agree on a format! Ha! > > > > It requires negotiation, but it's doable. > > Remember, all of this was done successfully for Firefox, which is a much > bigger and gnarlier codebase than Valgrind. I am not a fan, but also not dead against. Personally I am happy with emacs M-x indent-region on the code I edit. There is a .dir-locals.el in git which catches some (but certainly not all) formatting things. I played a bit with the .clang-format file. I am not sure I like using clang-format to reformat everything, it seems a little arbitrary. But if we could make the git-clang-format thing working then using that for formatting patches/regions that you changed might be OK. Cheers, Mark |