On 2023-02-02 Th 10:00, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Sure. There's probably some work that could still be done in this area
>> too, such as making pgperltidy work similarly to how we've now make
>> pgindent work.
> Perhaps. But before we commit to that, I'd like to see some tweaks to the
> pgperltidy rules to make it less eager to revisit the formatting of lines
> close to a change. Its current behavior will induce a lot of "git blame"
> noise if we apply these same procedures to Perl code.
I haven't done anything about that yet, but I have reworked the script
so it's a lot more like pgindent, with --show-diff and --silent-diff
modes, and allowing a list of files to be indented on the command line.
Non-perl files are filtered out from such a list.
>
> (Should I mention reformat-dat-files?)
If you want I can add those flags there too.
>
>> There's also a question of timing. Possibly the best time would be when
>> we next fork the tree.
> Yeah. We have generally not wanted to do a mass indent except
> when there's a minimum amount of pending patches, ie after the last
> CF of a cycle. What I'd suggest is that we plan on doing a mass
> indent and then switch over to the new rules, right after the March
> CF closes. That gives us a couple months to nail down and test out
> the new procedures before they go live.
>
>
WFM. Of course then we're not waiting for the developer meeting.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com