On 08/10, Junio C Hamano wrote: > Brandon Williams <bmw...@google.com> writes: > > > On 08/10, Junio C Hamano wrote: > > > >> I vaguely recall that there was a discussion to have SubmitGit wait > >> for success from Travis CI; if that is already in place, then I can > >> sort of see how it would help individual contributors to have the > >> style checker in that pipeline as well. > >> > >> I have a mixed feelings about "fixing" styles automatically, though. > > > > I still think we are far away from a world where we can fix style > > automatically. If we do want to keep pursuing this there are a number > > steps we'd want to take first. > > > > 1. Settle on a concrete style and document it using a formatter's rules > > (in say a .clang-format file). This style would most likely need to > > be tuned a little bit, at least the 'Penalty' configuration would > > need to be tuned which (as far as I understand it) is used to > > determine which rule to break first to ensure a line isn't too long. > > Yes. I think this is what you started to get the ball rolling. > Together with what checkpatch.pl already diagnoses, I think we can > get a guideline that is more or less reasonable. > > > 2. Start getting contributors to use the tool to format their patches. > > This would include having some script or hook that a contributor > > could run to only format the sections of code that they touched. > > This, too. Running checkpatch.pl (possibly combined with a bit of > tweaking it to match our needs) already catches many of the issues, > so a tool with a similar interface would be easy to use, I would > imagine. > > > 3. Slowly the code base would begin to have a uniform style. At > > some point we may want to then reformat the remaining sections of the > > code base. At this point we could have some automated bot that fixes > > style. > > I suspect I am discussing this based on a different assumption. > > I think the primary goal of this effort is to make it easier to > cleanse the new patches that appear on the list of trivial style > issues, so that contributors and reviewers do not have to spend > bandwidth and brain cycles during the review. And I have been > assuming that we can do so even without waiting for a "tree wide" > code churn on existing code to complete.
Yes that's one of the steps I missed we can call it 2.5 ;) (3) could be a long term goal which is what I was trying to get at by saying: > > 3. Slowly the code base would begin to have a uniform style. -- Brandon Williams
