Clang-format file draft / commit messages

[Dominik Röttsches]

Hi,

my 2 cents regarding the discussion on commit messages and
clang-format on the [patch] Simplify ftconfig.h thread, breaking out
into a separate thread.

1) While working on COLRv1 I also wanted to relieve myself from
manually formatting the code, so I've tried to step-by-step tweak a
.clang-format file which comes close to the current style. It still
has issues but is similar to the current style. More tweaking may
achieve getting us even a bit closer, though I am not sure we can get
there 100% (filing issues with clang-format may help further if
additional config options in the tool are needed):

My .clang-format file so far:

BasedOnStyle: GNU
AlignConsecutiveDeclarations: true
AlignConsecutiveAssignments: true
SpacesInParentheses: true
BinPackParameters: false
BinPackArguments: false
AlignAfterOpenBracket: true
AllowAllArgumentsOnNextLine: false
PointerAlignment: Right
BreakBeforeBraces: Allman
BreakBeforeBinaryOperators: None
AlignOperands: true

I'd not be opposed to changing to a different style completely and
running a full re-format. If there's interest in merging that already,
I can prepare a patch, but we may want to tweak this further before
landing.

2) Regarding commit messages / ChangeLog entries:

I'd be in favor of dropping manually formatted and added ChangeLog
entries and using the git history instead. I do understand Werner's
concern regarding a lack of descriptive commit messages, but this
could be improved / avoided by a review process before merging. (Tools
like GitHub or GitLab provide options to have syntactic and formatting
checks on the commit messages, to check for example for a column
limit, a bug reference or things like that). Plus the human review
could ensure that the commit messages are sufficiently descriptive.

Dominik

Re: [patch] Simplify ftconfig.h

[Alexei Podtelezhnikov]

>> It is far simpler to rely on the git history for this, and just
>> enforcing that committer provide meaningful commit messages should
>> be enough?
> 
> If we can do what Emacs does – namely git commit messages in ChangeLog
> style – I'm all for dropping direct ChangeLog entries.

GCC git-commit messages are very strictly formatted in Emacs style.  Do they 
use any tools?

On related note, git can nicely annotate diff hanks with function names, which 
is helpful for writing ChangeLog and commit messages. Can somebody write a 
regexp to help git recognize FreeType style?

Alexei