On Sat, Feb 4, 2023 at 12:37 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > But it's not clear to me why you're allergic to the perl wrapper? > It's not like that's the only perl infrastructure in our build process. > Also, whether or not we could push some of what it does into pg_bsd_indent > proper, I can't see pushing all of it (for instance, the very PG-specific > list of typedef exclusions).
I don't mind that there is a script. I do mind that it's not that good of a script. There have been some improvements for which I am grateful, like removing the thing where the first argument was taken as a typedefs file under some circumstances. But there are still some things that I would like: 1. I'd like to be able to run pgindent src/include and have it indent everything relevant under src/include. Right now that silently does nothing. 2. I'd like an easy way to indent the unstaged files in the current directory (e.g. pgindent --dirty) or the files that have been queued up for commit (e.g. pgindent --cached). 3. I'd also like an easy way to indent every file touched by a recent commit, e.g. pgindent --commit HEAD, pgindent --commit HEAD~2, pgindent --commit 62e1e28bf7. It'd be much less annoying to include this in my workflow with these kinds of options. For instance: patch -p1 < ~/Downloads/some_stuff_v94.patch # committer adjustments as desired git add -u pgindent --cached git diff # did pgindent change anything? does it look ok? git commit -a For a while I, like some others here, was trying to be religious about pgindenting at least the bigger commits that I pushed. But I fear I've grown slack. I don't mind if we tighten up the process, but the better we make the tools, the less friction it will cause. -- Robert Haas EDB: http://www.enterprisedb.com
