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
https://wiki.postgresql.org/wiki/Submitting_a_Patch#Reasons_your_patch_might_be_returned:
The fastest way to get your patch rejected is to make unrelated changes. Reformatting lines that haven't changed,
changingunrelated 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.
Thanks,
nm