Re: run pgindent on a regular basis / scripted manner
От | Andrew Dunstan |
---|---|
Тема | Re: run pgindent on a regular basis / scripted manner |
Дата | |
Msg-id | a7f96d6c-af5f-3249-90df-15131cb4a11e@dunslane.net обсуждение исходный текст |
Ответ на | Re: run pgindent on a regular basis / scripted manner (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: run pgindent on a regular basis / scripted manner
|
Список | pgsql-hackers |
On Sat, Aug 12, 2023 at 5:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:Hm. I was envisioning that we should expect committers to deal with this, not original patch submitters. So that's an argument against including it in the CI tests. But I'm in favor of anything we can do to make it more painless for committers to fix up patch indentation.
I agree with this.
Making it a special responsibility for committers comes with the same set of problems that we see with catversion bumps. People are much more likely to forget to do something that must happen last.
After I'd been caught by this once or twice I implemented a git hook test for that too - in fact it was the first hook I did. It's not perfect but it's saved me a couple of times:
check_catalog_version () {
# only do this on master
test "$branch" = "master" || return 0
case "$files" in
*src/include/catalog/catversion.h*)
return 0;
;;
*src/include/catalog/*)
;;
*)
return 0;
;;
esac
# changes include catalog but not catversion.h, so warn about it
{
echo 'Commit on master alters catalog but catversion not bumped'
echo 'It can be forced with git commit --no-verify'
} >&2
exit 1
}
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: