On 5/27/15 2:55 PM, Tom Lane wrote:
> These are all things we might try to fix (where "fix" could include
> "replace it with another tool") if the back-patching pain created by even
> minor changes of the formatting rules weren't so great. But at this point
> I despair of getting to consensus on a way to relieve that pain. Robert's
> position seems to be that there is no such pain, which I beg to differ
> with, but given that position he's naturally unwilling to accept any
> invasive measures to alleviate it.
I don't understand how this can be such a major problem. Both the
master branch and the back branch were once formatted by pgindent. The
only way things can diverge is if a poorly formatted patch is committed
to master, then backpatched, then pgindented in master but not in the
back branches, and then another patch needs to be applied on top of that.
The way to alleviate that problem is to make it easier and more likely
that the initial commit matches the preferred format and does not need
to be reindented later in major ways. But the current formatting
standard makes that very difficult for a number of reasons, to the point
that basically everyone has given up on it and lets pgindent sort it out
later. (This is a circular problem to an extent, of course.)
And even if we got to the point where all commits should be perfectly
pgindented, it wouldn't work, because under the current workflow the
updated typedef list isn't available until after the commit (on an
unpredictable schedule). (This problem would also affect pgindent in
back branches.)
If we found a tool setup (either a new tool, or a different (pg)indent
configuration) that addresses these problems and is future-proof, then I
think we could have a useful discussion about whether we want to
reformat the backbranches once or repeatedly or perhaps not. But I
don't see such a tool, and I've looked. So with the current setup, I
think reformatting master once a year and leaving the back branches
alone is the best scenario.