Re: Why --backup-and-modify-in-place in perltidy config?

On Mon, Aug 15, 2016 at 11:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

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