Re: run pgindent on a regular basis / scripted manner

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: run pgindent on a regular basis / scripted manner
Дата
Msg-id 00885533-ff96-2a95-7911-329c873b3029@dunslane.net
обсуждение исходный текст
Ответ на Re: run pgindent on a regular basis / scripted manner  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: run pgindent on a regular basis / scripted manner
Re: run pgindent on a regular basis / scripted manner
Список pgsql-hackers


On 2023-02-10 Fr 10:21, Andrew Dunstan wrote:


On 2023-02-10 Fr 04:25, Jelte Fennema wrote:
Ah yes, I had seen that when I read the initial --commit patch but
then forgot about it when the flag didn't work at all when I tried it.

Attached is a patch that fixes the issue. And also implements the
--dirty and --staged flags in pgindent that Robert Haas requested.



I don't think just adding a diff filter is really a sufficient fix. The file might have been deleted since the commit(s) in question. Here's a more general fix for missing files.


OK, I've pushed this along with a check to make sure we only process each file once.


I'm not sure how much more I really want to do here. Given the way pgindent now processes command line arguments, maybe the best thing is for people to use that. Use of git aliases can help. Something like these for example


[alias]

    dirty = diff --name-only --diff-filter=ACMU -- .
    staged = diff --name-only --cached --diff-filter=ACMU -- .
    dstaged = diff --name-only --diff-filter=ACMU HEAD -- .


and then you could do

    pgindent `git dirty`


The only danger would be if there were no dirty files. Maybe we need a switch to inhibit using the current directory if there are no command line files.


Thoughts?


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Making aggregate deserialization (and WAL receive) functions slightly faster
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?