All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Stefan Beller <sbeller@google.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [RFC] clang-format: outline the git project's coding style
Date: Tue, 8 Aug 2017 11:23:24 -0700	[thread overview]
Message-ID: <20170808182324.GB73298@google.com> (raw)
In-Reply-To: <CAGZ79kb2860nUs46bP=x-gAx9Ao6DxnvXQv3x387Wxw+kEyxJw@mail.gmail.com>

On 08/08, Stefan Beller wrote:
> On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Hi Brandon,
> >
> > On Mon, 7 Aug 2017, Brandon Williams wrote:
> >
> >> Add a '.clang-format' file which outlines the git project's coding
> >> style.  This can be used with clang-format to auto-format .c and .h
> >> files to conform with git's style.
> >>
> >> Signed-off-by: Brandon Williams <bmwill@google.com>
> >> ---
> >>
> >> I'm sure this sort of thing comes up every so often on the list but back at
> >> git-merge I mentioned how it would be nice to not have to worry about style
> >> when reviewing patches as that is something mechanical and best left to a
> >> machine (for the most part).
> >
> > Amen.
> >
> > If I never have to see a review mentioning an unwrapped line, I am quite
> > certain I will be quite content.
> >
> > Ciao,
> > Dscho
> 
> As a thought experiment I'd like to propose to take it one step further:
> 
>   If the code was formatted perfectly in one style such that a formatter for
>   this style would not produce changes when rerun again on the code, then
>   each individual could have a clean/smudge filter to work in their preferred
>   style, and only the exchange and storage of code is in a mutual agreed
>   style. If the mutually agreed style is close to what I prefer, I don't have to
>   use clean/smudge filters.
> 
> Additionally to this patch, we'd want to either put a note into
> SubmittingPatches or Documentation/gitworkflows.txt to hint at
> how to use this formatting to just affect the patch that is currently
> worked on or rather a pre-commit hook?

I'm sure both of these things will probably happen if we decide to make
use of a code-formatter.  This RFC is really just trying to ask the
question: "Is this something we want to entertain doing?"
My response would be 'Yes' but there's many other opinions to consider
first :)

-- 
Brandon Williams

  reply	other threads:[~2017-08-08 18:23 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08  1:25 [RFC] clang-format: outline the git project's coding style Brandon Williams
2017-08-08 12:05 ` Johannes Schindelin
2017-08-08 17:40   ` Stefan Beller
2017-08-08 18:23     ` Brandon Williams [this message]
2017-08-09 22:33       ` Johannes Schindelin
2017-08-09 22:42         ` Stefan Beller
2017-08-10  9:38           ` Johannes Schindelin
2017-08-10 16:41             ` Junio C Hamano
2017-08-10 17:15               ` Brandon Williams
2017-08-10 17:28                 ` Junio C Hamano
2017-08-10 21:30                   ` Brandon Williams
2017-08-11 20:06                     ` Ben Peart
2017-08-14 15:52               ` Johannes Schindelin
2017-09-28 11:41         ` Johannes Schindelin
2017-09-28 17:16           ` Brandon Williams
2017-08-08 17:45 ` Junio C Hamano
2017-08-08 18:03   ` Brandon Williams
2017-08-08 18:25     ` Junio C Hamano
2017-08-09  7:05       ` Junio C Hamano
2017-08-11 17:49         ` Brandon Williams
2017-08-11 19:00           ` Junio C Hamano
2017-08-09 13:01 ` Jeff King
2017-08-09 14:03   ` Ævar Arnfjörð Bjarmason
2017-08-09 22:53     ` Stefan Beller
2017-08-09 23:11       ` Stefan Beller
2017-08-11 17:52         ` Brandon Williams
2017-08-11 21:18           ` Jeff King
2017-08-12  4:39             ` Junio C Hamano
2017-08-13  4:41               ` Jeff King
2017-08-13 16:14                 ` Ramsay Jones
2017-08-13 16:36                   ` Ramsay Jones
2017-08-13 17:33                   ` Junio C Hamano
2017-08-13 19:17                     ` Ramsay Jones
2017-08-09 23:19       ` Jeff King
2017-08-15  0:40         ` brian m. carlson
2017-08-15  1:03           ` Jonathan Nieder
2017-08-14 21:30 ` [PATCH v2 0/2] clang-format Brandon Williams
2017-08-14 21:30   ` [PATCH v2 1/2] clang-format: outline the git project's coding style Brandon Williams
2017-08-14 22:02     ` Stefan Beller
2017-08-15 13:56       ` Ben Peart
2017-08-15 17:37         ` Brandon Williams
2017-08-14 22:48     ` Jeff King
2017-08-14 22:51       ` Jeff King
2017-08-14 22:54         ` Brandon Williams
2017-08-14 23:01           ` Jeff King
2017-08-16 12:18             ` Johannes Schindelin
2017-08-15 14:28     ` Ben Peart
2017-08-15 17:34       ` Brandon Williams
2017-08-15 17:41         ` Stefan Beller
2017-08-14 21:30   ` [PATCH v2 2/2] Makefile: add style build rule Brandon Williams
2017-08-14 21:53     ` Stefan Beller
2017-08-14 22:25     ` Junio C Hamano
2017-08-14 22:28       ` Stefan Beller
2017-08-14 22:57         ` Jeff King
2017-08-14 23:29           ` Junio C Hamano
2017-08-14 23:47             ` Junio C Hamano
2017-08-15  0:05               ` Brandon Williams
2017-08-15  1:52               ` Jeff King
2017-08-14 21:32   ` [PATCH v2 0/2] clang-format Brandon Williams
2017-08-14 23:06   ` Jeff King
2017-08-14 23:15     ` Stefan Beller
2017-08-15  1:47       ` Jeff King
2017-08-15  3:03         ` Junio C Hamano
2017-08-15  3:38           ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170808182324.GB73298@google.com \
    --to=bmwill@google.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.