Policy for automated code reformatting?

[Jean Abou Samra]

Hi,

We talked several times about automated code reformatting these times,
the last instance being 
https://gitlab.com/lilypond/lilypond/-/merge_requests/375.
There is general agreement (I think) that we need some way of 
maintaining the quality
of Python code in particular. I feel it'd be hard to impose a certain 
formatting tool
to be run on each Merge Request. On the other hand, automated 
reformattings, if not
practised by everyone, affect other parts of the same file, which 
doesn't facilitate
review, and there is the git blame issue. I propose a compromise here, 
with a policy to
harmonize things a bit:

   New code is required to comply with the project's coding style; 
older code *can* be
   updated to follow this style. Developers *may* use ``fixcc``, 
``fixscm`` and ``autopep8``
   to reformat code automatically as part of a Merge Request. In doing 
so, developers *may*
   reformat other parts of the same file that would otherwise be left 
untouched by their
   patch. In this case, the reformatting *must* be done in a separate 
commit. Under normal
   circumstances, reformattings *should* be limited to single files.

Rationale:
- Those who so like can use these tools freely on the code they write.
- Reviewers can review commits, so they may skip the reformatting.
- There does not need to be a countdown just for the reformatting.
- Don't hamper the usability of git blame too much, only reformat code 
when it
  is modified.

What do you think?

Cheers,
Jean