Andrew Dunstan <and...@dunslane.net> writes:
>>> I think we could do better with some automation tooling for committers
>>> here. One low-risk and simple change would be to provide a
>>> non-destructive mode for pgindent that would show you the changes if any
>>> it would make. That could be worked into a git pre-commit hook that
>>> committers could deploy. I can testify to the usefulness of such hooks -
>>> I have one that while not perfect has saved me on at least two occasions
>>> from forgetting to bump the catalog version.
That sounds like a good idea from here. I do not think we want a
mandatory commit filter, but if individual committers care to work
this into their process in some optional way, great! I can think
of ways I'd use it during patch development, too.
(One reason not to want a mandatory filter is that you might wish
to apply pgindent as a separate commit, so that you can then
put that commit into .git-blame-ignore-revs. This could be handy
for example when a patch needs to change the nesting level of a lot
of pre-existing code, without making changes in it otherwise.)
>> This time with patch.
> ... with typo fixed.
Looks reasonable, but you should also update
src/tools/pgindent/pgindent.man, which AFAICT is our only
documentation for pgindent switches. (Is it time for a
--help option in pgindent?)
regards, tom lane
