[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: astyle 2.02

From: Graham Percival
Subject: Re: astyle 2.02
Date: Sun, 29 Jun 2014 13:10:11 +0900
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jun 29, 2014 at 12:08:56AM +0200, Janek Warchoł wrote:
> If "badly formatted" <=> "different than what would produce",
> i would say that LilyPond often gets badly formatted code - as you
> wrote, running fixcc now results in 400 lines of changes.

This could, of course, be completely automated.  Once has
been run on the whole source code, each patch could be tested to
see if running on it produces any changes.  If so, then
the patch would be automatically rejected and the submitter would
be asked to run before re-submitting the patch.  A less
strict method of this would be to simply produce an automated
warning.  Or this could be deferred to the "merge staging" side of
things -- if produces any changing on staging, then it is
not merged with master.

The question to ask is where do you want the burden of producing
properly formatted code?

- a volunteer who runs manually once a year?
  (this also produces "code reformatting" commits which disrupt
  git blame)
- an automated process which demands that the initial submitter
  format the patch?
- an automated process which demands that the pusher format the
  (note that with new or casual committers, the pusher is not
  the same as the committer)

I favour the first or third option; people heavily involved in
lilypond can set up a git hook and always have properly formatted
code (whether they write the patch themselves or simply push
somebody else's patch).  Asking casual committers to have a
specific version of astyle seems like a high burden.

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]