On Wed, Jan 13, 2016 at 12:13:11PM -0500, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: > > On 13 January 2016 at 14:48, Noah Misch <noah@leadboat.com> wrote: > >> I've noticed commits, from a few of you, carrying pgindent changes to lines > >> the patch would not otherwise change. > > > Could we review again why this matters? > > Basically this is trading off convenience of the committer (all of the > alternatives Noah mentions are somewhat annoying) versus the convenience > of post-commit reviewers. I'm not sure that his recommendation is the > best trade-off, nor that the situation is precisely comparable to > pre-commit review. There definitely will be pre-commit review, there > may or may not be any post-commit review.
That's a good summary. > I'm willing to go with the "separate commit to reindent individual files" > approach if there's a consensus that that makes for a cleaner git history. > But I'm not 100% convinced it matters.
Thanks.
My objective in committing patches to PostgreSQL is to develop the Open Source version of PostgreSQL as a standalone product and I encourage others to do the same.
PostgreSQL is open source and therefore usable for various additional purposes, one of which is modified versions of PostgreSQL.
I will not go out of my way to cause problems for the secondary users of the code. I will try to implement one of the suggestions for whitespace handling, though may make mistakes in that, nobody being perfect.
The secondary purposes of the code can only occur if the core code lives and breathes, so I expect such users to make positive contributions to core directly and not to block or slow down inclusion of features by others. Quid pro quo.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
