Horton

Re: Preliminary results for proposed new pgindent implementation

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Piotr Stefaniak <postgres@piotr-stefaniak.me>
Date: 2017-06-16T18:54:06Z
Lists: pgsql-hackers 
On 2017-06-16 14:42:38 -0400, Bruce Momjian wrote:
> On Fri, Jun 16, 2017 at 02:23:00PM -0400, Tom Lane wrote:
> > Well, that's something we need to discuss.  I originally argued for
> > back-patching the new rules, whatever they are (ie, run the new
> > pgindent on the back branches whenever we've agreed that the dust
> > has settled).  But I'm starting to realize that that's likely to
> > be horrid for anyone who's carrying out-of-tree patches, as I know
> > a lot of packagers do for instance.  We have to trade off our own
> > inconvenience in making back-patches against inconvenience to
> > people who are maintaining private patchsets.
> 
> Can't they sync up to just before our pgindent commit and run pgindent
> on their own code base?

That doesn't really help that much if you have a series of patches that
you want to keep independent, e.g. because you might want to submit to
postgres.  And you'll also get a bunch of annoying to resolve merge
conflicts, even if they're easier to resolve with that methodology.

- Andres

Commits

  1. Manually un-break a few URLs that pgindent used to insist on splitting.

  2. Remove entab and associated detritus.

  3. Phase 3 of pgindent updates.

  4. Phase 2 of pgindent updates.

  5. Initial pgindent run with pg_bsd_indent version 2.0.

  6. Adjust pgindent script to use pg_bsd_indent 2.0.

  7. Final pgindent run with old pg_bsd_indent (version 1.3).