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
