[Users] Reformatting Carpet's source code

Roland Haas rhaas at aei.mpg.de
Sun Jul 5 07:47:37 CDT 2015


Hello all,

> Usually, changing the source code format is disruptive, since patches or
> local modifications won't apply cleanly any more. However, with
> clang-format, I don't think that this is an issue -- one can use
> clang-format on the modified code (e.g. a branch), which should eliminate
> gratuitous changes.
I tend to not like reformatting code, since I am just now struggling
re-integrating changes into SpEC where the original author realigned
code lines to look "nicer". I effectively end up having to re-implement
the changes since git merge simply cannot deal with the amount of
changes present.

My reasons are basically the ones Ian outlined: using diff between pre
and post-format revisions becomes almost impossible. I also suspect that
there are instances where a particular indentation is desired to eg
align different conditions in a long if statement that clang-format
would not capture properly.

Do you have a particular version you would like to use? Debian adds the
version number to its clang-format package names which tends to be an
indication that the different versions are not drop-in replacements for
each other. We'd definitely want to avoid an automated formatting war
due to different clang-format versions producing different output.

On the level of things that mostly affect myself: I have many local
branches with multiple commits past the branching point. Would you know
already how to use clang-format to have all commits in there reformatted
so that I can rebase them onto the master (eg to propose a pull
request)? Otherwise the option would seem to be to have a "reformat with
clang" commit in each branch and do an actual git-merge to bring the
branches up to date with master. So far merges have been rare and seemed
frowned upon.

If one only wants to have clang-format take care of newly added code,
which may be less disruptive and still frees the authors from having to
worry about formatting, then one can (hopefully) use this:

https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format

which should be executed before "git add".

In the end though, I think that the main author gets to choose the
coding style they would like to use (unless the code is in Cactus in
which case he Cactus coding style applies). If this is "clang-formatted
all the way down" then so be it.

Yours,
Roland


More information about the Users mailing list