> On Jan 13, 2016, at 9:13 AM, Tom Lane <tgl@sss.pgh.pa.us> 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.
>
> 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.
As somebody who maintains a fork of the code base, I can say it is easier
to deal with merge conflicts when work is broken out into smaller commits.
Separating whitespace and formatting changes into their own commits
would make my life a little easier.
OTOH, I don't know if the core developer community cares about the ease
of maintaining code forks.
mark
