On 10/02, Junio C Hamano wrote: > From: Stephan Beyer <s-beyer@xxxxxxx> > > Having a .clang-format file in a project can be understood in a way that > code has to be in the style defined by the .clang-format file, i.e., you > just have to run clang-format over all code and you are set. > > This unfortunately is not yet the case in the Git project, as the > format file is still work in progress. Explain it with a comment in > the beginning of the file. > > Additionally, the working clang-format version is mentioned because the > config directives change from time to time (in a compatibility-breaking way). > > Signed-off-by: Stephan Beyer <s-beyer@xxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > > * So here is a counter-proposal in a patch form. I agree that my > earlier suggestion was unnecessarily verbose; this one spends > just as many lines and not more than the v2 round of Stephan's > patch. > > .clang-format | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/.clang-format b/.clang-format > index 56822c116b..7670eec8df 100644 > --- a/.clang-format > +++ b/.clang-format > @@ -1,4 +1,8 @@ > -# Defaults > +# This file is an example configuration for clang-format 5.0. > +# > +# Note that this style definition should only be understood as a hint > +# for writing new code. The rules are still work-in-progress and does > +# not yet exactly match the style we have in the existing code. Thanks for writing up this header comment to the .clang-format file, it's something I definitely should have included when I introduced it. And I like the wording that you've both settled on, as it reflects our intentions (of having the code eventually conform to the format rules) and making note that this set of rules still needs to be tuned. Thanks! > > # Use tabs whenever we need to fill whitespace that spans at least from one tab > # stop to the next one. > -- > 2.14.2-820-gefeff4fbff > -- Brandon Williams
