Automatically add a pre-commit hook to git repos for running clang-fo…

[hernando]

…rmat.

The pre-commit hook is a bash script using only built-ins, git and
clang_format. The hook is not added if the project being configured already
has one.
The script does nothing if a .clang-format is not found and it only processes
files that are added enterily to the index.

[eile]

If I understand correctly, this applies only to fully staged files? What if I do a git commit -a?

[hernando]

I tested just in case, clang-format is still run on all modified files. Git seems to prepare the index before calling the pre-commit hook, and if you abort the commit it undoes the additions to the index.

[eile]

-style=file?

[hernando]

That's what man clang-format told me to do. Has this changed in a later version?

[rdumusc]

this will hardcode a path at configure time, not a good idea because this file will not be overwritten once it has been created. Just use the executable from the path?

[hernando]

And what if your git or clang format binaries are not in the path and you detected them with CMake?

[rdumusc]

In general I have some concerns with this approach. It is a somewhat hidden feature that changes the code behind the back of users when they just want to commit.

In terms of implementation, the .clang-format file will have to be committed in each project, and any change to our coding style will have to be replicated everywhere. If on the other hand we use a hard-coded clang-format -style {options...}, then that would be quite bad for external users who have a different coding style...

I am trying to think of a better automated solution. One option could be a per-project CMake target ${PROJECT_NAME}-clang-format that applies our coding style by default (using hard-coded clang-format -style {options...}) but will apply a ${PROJECT_SOURCE_DIR}/.clang-format instead if one is found. That way we can provide a centralized default style without impacting external users, and the formatting becomes explicit instead of implicit. This adds only one pre-commit step for external contributors who want to submit a patch to our projects. For us, we can simply configure our IDEs to apply clang-format when saving the file (e.g. Beautifier plugin in QtCreator).

[hernando]

I don't know if everybody knows his IDE, but your solution means that unless you configure it for all the systems you use, you have to run the pre commit step manually to make sure you will pass CI. I see this problematic for smooth adoption inside our team.
Personally, I prefer the approach I implemented. It can be modified to ask the user interactively what to do if there are differences between the staging area and the working copy after clang-format is run (I'd give four options: accept, see diff, reject and accept for all files)

[rdumusc]

Setting the IDE is not an overly complex task, I am sure every developer has already some presets like replace tabs with whitespace, remove trailing whitespaces, etc... sure, if you work on multiple systems you have to do it everywhere, but the same applies to you ~/.bashrc aliases, ~/.gitconfig, etc...
That being said, it is of course a matter of personal preference. Maybe we should discuss the options together to see what the majority prefers.

[tribal-tec]

I'm happy with @hernando 's solution. Can we find a speedy conclusion and move forward? Looks already a bit tumbleweed here...

[rdumusc]

Fair enough, I will accept the decision of the majority, but I let someone else approve this PR since I don't ;-)