Side thought: if your CPP code is complex, indenting it helps readability a lot, here's a goofy example
#if CONDITION # define AMACRO 6 # include "some/file.h" #else # if WIN32 # include "something/else.h" # elif MACOSX # include "the/darwin/version.h" # endif #endif I haven't seen clang-format formats that do this before, but on my code I'd have it leave CPP code alone if it didn't do this L On Tue, 6 Sep 2022, 20:56 Jonas Hahnfeld via Discussions on LilyPond development, <lilypond-devel@gnu.org> wrote: > On Tue, 2022-09-06 at 18:46 +0200, Jean Abou Samra wrote: > > There's one thing I'd like to discuss now, for the reformatting round > > before we do the branching. > > (Yes, I didn't manage yet to propose the reformatting. I'd like to do > this after 2.23.13 is released. As a reminder, the idea is that we > introduce a bit of churn before branching, but then don't get into > trouble when backporting fixes to the branch.) > > > I would like to propose moving to clang-format as the canonical > > formatting tool and removing fixcc.py. This will decrease our > > maintenance burden. fixcc.py is more than 600 lines of code to > > maintain. > > In general I'm not opposed. However, please note that clang-format is > sometimes not stable over time, ie new versions can change formatting. > Most projects use git-clang-format to incrementally format only the > lines touched by commits. In LilyPond, the current practice is to > format all code files, so we will experience this to its fullest. I > don't know if that's going to be a problem, but I thought I'd mention > it. > > > These days, git blame supports the --ignore-rev option, which makes > > this less painful for future code historians. > > We can also have a .git-blame-ignore-revs in the repository. This > already works on GitHub, and there is an open issue to also support it > in GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/31423 > > > It will obviously still produce merge conflicts with existing WIP > branches. > > Usually branches can be "updated" by also running the (same) formatting > tool on the changes, and then either git manages to resolve things > itself or you can "port" the diff. > >
