From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why --backup-and-modify-in-place in perltidy config? |
Date: | 2016-08-15 14:19:12 |
Message-ID: | 6816.1471270752@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 08/14/2016 04:38 PM, Tom Lane wrote:
>> I did a trial run following the current pgindent README procedure, and
>> noticed that the perltidy step left me with a pile of '.bak' files
>> littering the entire tree. This seems like a pretty bad idea because
>> a naive "git add ." would have committed them. It's evidently because
>> src/tools/pgindent/perltidyrc includes --backup-and-modify-in-place.
BTW, after experimenting with this, I did not find any way to get perltidy
to overwrite the original files without making a backup file.
> We should probably specify -bext='/', which would cause the backup files
> to be deleted unless an error occurred.
Really? That seems a bit magic, and it's certainly undocumented.
> Alternatively, we could just remove the in-place parameter and write a
> command that moved the new .tdy files over the original when perltidy
> was finished.
I was thinking about just removing all the .bak files afterwards, ie
automating the existing manual process. As long as we're making an
invocation script anyway, that's easy.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Anastasia Lubennikova | 2016-08-15 14:45:58 | Re: WIP: Covering + unique indexes. |
Previous Message | Andrew Dunstan | 2016-08-15 14:12:32 | Re: Why --backup-and-modify-in-place in perltidy config? |