Re: Run pgindent now? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Run pgindent now?
Date
Msg-id 17081.1432045590@sss.pgh.pa.us
Whole thread Raw
In response to Re: Run pgindent now?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Run pgindent now?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 18, 2015 at 6:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Would it alleviate your concern any if we eased into this, like say only
>> apply the back-branch pgindent run to 9.5 and later branches?  Then at
>> least I could foresee the end of that particular annoyance.

> If we do this only beginning with 9.5, and if we can make the output
> 100% consistent across branches, and if we run it before EVERY minor
> release so that people don't see unrelated diffs between consecutive
> tarballs, then it would address my concerns.

To do it before every minor release would require re-indenting HEAD
as well (since the whole point is to keep HEAD and the back branches
consistent).  I think we'd get too much push-back from developers
whose pending patches got broken.  We can get away with reindenting
HEAD between development cycles, but probably not more often than that.

I'm not particularly concerned by the tarball-diff argument: running
diff with --ignore-spaces should mask most of the changes.  Moreover,
assuming the code was properly indented at x.y.0 release time, any
changes applied by pgindent would only be within subsequent back-patches,
which hopefully are a very small part of the code.  (Perhaps it would be
useful to do a trial indent on some old branch right now, just to see how
large the diffs are; then we'd have some actual facts in this argument...)

And lastly, committers who are bothered by the prospect of such changes
could take the time to reindent their back-patched changes before
committing in the first place.  (FWIW, I usually do, and it's not hard
except in files that have been heavily mangled in HEAD.)

> I wish that pgident could be made more automated, like by having it
> fully built into the tree so that you can type 'make indent', or by
> having a daemon that would automatically pgindent the main tree
> periodically (say, once a month, or when more than X number of
> lines/files have changed, whichever comes first).  I still find it
> quite a hassle to set up and run.

It is a pain.  I have a shell script that fetches the typedef list
automatically, which helps.  The main problem with a "make indent" target
is that only in Bruce's annual runs do we really want to let it loose on
the whole tree.  In manual fixups, I only point it at the files I've
edited (and then, often, I have to remove some diffs in unrelated parts
of those files).  I wish that could be a bit easier, though I'm not sure
how.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: a few thoughts on the schedule
Next
From: Dave Cramer
Date:
Subject: Re: Problems with question marks in operators (JDBC, ECPG, ...)