Re: Why --backup-and-modify-in-place in perltidy config? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Why --backup-and-modify-in-place in perltidy config?
Date
Msg-id CAB7nPqSknXwVh-Eqq=pFMh2judMpHEfT53+RXZ8CGJ5hwV2+WA@mail.gmail.com
Whole thread Raw
In response to Re: Why --backup-and-modify-in-place in perltidy config?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why --backup-and-modify-in-place in perltidy config?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Aug 15, 2016 at 11:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.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.

The tree does not have any .bak file, and those refer to backup copies
normally. Perhaps it would make sense to include those in root's
.gitignore? That would save from an unfortunate manipulation of git
add in the future.
-- 
Michael



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: PSA: Systemd will kill PostgreSQL
Next
From: Michael Paquier
Date:
Subject: Re: Anyone want to update our Windows timezone map?