Chris Browne <cbbrowne@acm.org> writes:
> Would it be a terrible idea to...
>
> - Draw the indent code from NetBSD into src/tools/pgindent
I am not real eager to become maintainers of our own indent fork, which
is what you propose. (Just for starters, what will we have to do to
make it run on non-BSD systems?)
> We are presently at the extreme position where pgindent is run once in
> a very long time (~ once a year), at pretty considerable cost, and
> with the associated cost that a whole lot of indentation problems are
> managed by hand.
Yeah. One reason for that is that the typedef problem makes it a pretty
manual process.
The main problem I see with "pgindent early and often" is that it only
works well if everyone is using exactly the same pgindent code (and
exactly the same typedef list). Otherwise you just get buried in
useless whitespace diffs.
It's bad enough that Bruce whacks around his copy from time to time :-(.
I would say that the single greatest annoyance for maintaining our back
branches is that patches tend to not back-patch cleanly, and well over
half the time it's because of random reformattings done by pgindent
to code that hadn't changed at all, but it had formatted differently
the prior year.
For the same reason, my take on your "random whitespace changes are
acceptable" theory is not no but hell no. It's gonna cost us,
permanently, in manual patch adjustments if we allow the repository to
get cluttered with content-free diffs.
I guess an advantage of maintaining our own fork is that there'd be Only
One True pgindent, thereby alleviating that problem; but I'm still not
eager to go there. If we were going to do it, I'd really wish that we
could standardize on a version that didn't need a typedef list. The
random whitespace changes you get after changing the typedef list are
another thorn in my side.
But in any case, this is all focusing on trivialities. The stuff
pgindent can fix is, by definition, stuff that committers don't really
have to worry about during patch review. The stuff I'm worried about
is at a higher level than that.
regards, tom lane
