Re: Replacing fixcc.py with clang-format?

[Jonas Hahnfeld]

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.

signature.asc
Description: This is a digitally signed message part