Hi, On Tue, 8 Aug 2017, Brandon Williams wrote:
> On 08/08, Stefan Beller wrote: > > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin > > <johannes.schinde...@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 <bmw...@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 :) I am sure that something even better will be possible: a Continuous "Integration" that fixes the coding style automatically by using `filter-branch` (avoiding the merge conflicts that would arise if `rebase -i` was used). Ciao, Dscho
