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

2016-08-22 Thread Bruce Momjian
On Mon, Aug 15, 2016 at 10:19:12AM -0400, Tom Lane wrote: > Andrew Dunstan 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 >

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

2016-08-15 Thread Gavin Flower
On 16/08/16 16:19, Andrew Dunstan wrote: On 08/15/2016 02:23 PM, Tom Lane wrote: Andrew Dunstan writes: On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan writes: We should probably specify -bext='/', which would cause the backup files to be

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

2016-08-15 Thread Andrew Dunstan
On 08/15/2016 02:23 PM, Tom Lane wrote: Andrew Dunstan writes: On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan writes: We should probably specify -bext='/', which would cause the backup files to be deleted unless an error occurred. Really?

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

2016-08-15 Thread Tom Lane
Michael Paquier writes: > 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. We've

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

2016-08-15 Thread Michael Paquier
On Mon, Aug 15, 2016 at 11:19 PM, Tom Lane wrote: > Andrew Dunstan 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

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

2016-08-15 Thread Tom Lane
Andrew Dunstan writes: > On 08/15/2016 10:19 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> 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

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

2016-08-15 Thread Andrew Dunstan
On 08/15/2016 10:19 AM, Tom Lane wrote: Andrew Dunstan 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.

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

2016-08-15 Thread Tom Lane
Andrew Dunstan 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

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

2016-08-15 Thread Andrew Dunstan
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.

[HACKERS] Why --backup-and-modify-in-place in perltidy config?

2016-08-14 Thread Tom Lane
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