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 _______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
