I've noticed commits, from a few of you, carrying pgindent changes to lines
the patch would not otherwise change.  (That is to say, the next pgindent run
would have made the same changes anyway.)  From

  The fastest way to get your patch rejected is to make unrelated changes.
  Reformatting lines that haven't changed, changing unrelated comments you
  felt were poorly worded, touching code not necessary to your change, etc.

Commits should follow the same high standards we ask of submissions.  Several
pgindent strategies do conform:

1) Run pgindent, then manually reduce its changes to the subset that your
   patch caused.
2) Don't run pgindent yourself; commit code that pgindent may later change.
3) Push a commit containing nothing but a pgindent run of the files you care
   about, then push a second commit for your feature/bugfix.

Please use of one of those next time you'd run pgindent.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to