On Tue, May 26, 2015 at 2:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> This is kind of why I think that reindenting the back branches is
> unlikely to be productive: it only helps if you can get pgindent to do
> the same thing on all branches, and I bet that's going to be tough.
...but having said that and thought about this a bit more, we could
actually test that rather than guessing.
Suppose somebody goes and writes a script which diffs the version of
each file on master with the version of the same file, if it exists,
on each stable branch. And then they indent each back-branch on a
private branch and do the same thing again. And then they produce a
report of every file where the number of lines that differ went up
rather than down. Then, we could look at the files where things got
worse and try to fix whatever the issue is.
Of course, it would be nice to be even more fine-grained and try to
figure out whether there are files where, although the file overall
ended up with fewer differences, some individual places in the file
diverged. Maybe somebody with sufficient git-fu could figure out how
to do that. But even without that, it seems to me that with some
work, we could probably measure how good an outcome we're actually
going to get here.
What I really don't want to do is apply the pgindent diff somewhat
blindly, without really knowing how many cases we're improving and how
many cases we're making worse. The number of times we've run pgindent
and then realized later that it messed a bunch of stuff up is actually
pretty high, and I find doing that to the back-branches particularly
unexciting.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
