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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel