In the past, we've discussed the possibility of using an automatic code
formatter for Git.  That discussion has, as we've seen, not led to us
using one.  I'd like to reopen the discussion and provide a couple
reasons why I think it's a good idea.

We've spent a lot of work encouraging newcomers to contribute to Git.
It's demoralizing when your code comes back with many code style nits to
fix, and it leads to a barrier to contribution.  I also find that I am
likely to take longer to reroll a series if there are many nits to be
fixed, and I find that code style comments are a frequent discussion
topic on my series (even though I generally try to be cognizant of
them).

Having a code formatting tool means that the work for a contributor to
format the file properly consists of about two keystrokes.  This
substantially reduces the amount of time that contributors must spend
thinking about code formatting and simplifies it to an automatic process
that, if we choose, can even be verified in CI.

Most projects written in languages like Rust or Go use an automatic
formatter.  In Go's case, the formatter is specifically stated to be a
fixed style that is nobody's favourite, but because there's an automatic
formatter, everybody just uses it.  Personally, I don't love our coding
style now (I'm a 4-space person in C), but I would love it a lot more if
I didn't have to think about it.  I am substantially less picky about
what the style is than that we have an automated tool to tidy our code,
and I'm okay with us producing the occasional slightly suboptimal style
for the improved efficiency we get.

The impetus for me bringing this up is that I'm rebasing the
SHA-1/SHA-256 interop work to continue work on it and I find myself
spending a lot of time cleaning up formatting that I could instead be
spending on debugging why my tests are failing or writing new code.  I
would like to spend less time on boring scut work and more time solving
interesting problems, as I'm sure we all would.

I should point out that most platforms (and all major platforms) have
clang and therefore I think clang-format should be a fine choice.  It's
highly configurable and will let us pick a style that most resembles the
one we have now. However, I'm not picky and if we like something else
better, great.  As long as the option we pick is shipped in Debian, I'm
for it.

I should note that we already have a .clang-format file, so we can
already use clang-format.  However, we cannot blindly apply it because
it produces output that is not always conformant with our style.  My
proposal here is to define our style in terms of the formatter to avoid
this problem.

Hopefully we can move forward with this discussion and come to some
productive resolution.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA