Re: astyle 2.02

[Graham Percival]

On Sun, Jun 29, 2014 at 12:08:56AM +0200, Janek Warchoł wrote:
> If "badly formatted" <=> "different than what fixcc.py 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 fixcc.py has
been run on the whole source code, each patch could be tested to
see if running fixcc.py on it produces any changes.  If so, then
the patch would be automatically rejected and the submitter would
be asked to run fixcc.py 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 fixcc.py 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 fixcc.py 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
  patch?
  (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.

Cheers,
- Graham