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

On Tue, May 19, 2015 at 10:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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 convinced of that.  If we did it more often, it might actually
be less disruptive.

> 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...)

That parenthetical idea sounds promising.

> 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.)

Meh.  With 10+ active committers, that's bound not to always work out.

>> 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.

Unless we reindent regularly, the problem with changes in unrelated
parts of the file is not going away.  Figuring out which files have
been changed locally could probably be done with some sort of git-fu.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company