Peter Eisentraut writes:
> On 24.04.23 16:14, Tom Lane wrote:
>> I certainly don't like its current behavior where adding/changing one
>> line can have side-effects on nearby lines. But we have a proposal
>> to clean that up, and I'm cautiously optimistic that it'll be better
>> in future. Did
On 24.04.23 16:14, Tom Lane wrote:
Peter Eisentraut writes:
Does anyone find perltidy useful? To me, it functions more like a
JavaScript compiler in that once you process the source code, it is no
longer useful for manual editing. If we are going to have the buildfarm
check indentation and
Peter Eisentraut writes:
> Does anyone find perltidy useful? To me, it functions more like a
> JavaScript compiler in that once you process the source code, it is no
> longer useful for manual editing. If we are going to have the buildfarm
> check indentation and that is going to be extended
On 23.04.23 17:29, Jelte Fennema wrote:
On Sun, 23 Apr 2023 at 17:16, Tom Lane wrote:
I think we could go ahead and commit the perltidyrc and README changes
now. But the ensuing reformatting should happen as part of the mass
pgindent run, probably next month sometime.
I think it's better to
On Sat, Apr 22, 2023 at 9:59 PM Noah Misch wrote:
>
> (Given that another commentator is "absolutely against" a hook, this message
> is mostly for readers considering this for other projects.)
>
> On Sat, Apr 22, 2023 at 03:23:59PM +0200, Magnus Hagander wrote:
> > On Tue, Feb 7, 2023 at 5:43 AM
On Sat, Apr 22, 2023 at 4:12 PM Andrew Dunstan wrote:
>
>
> On 2023-04-22 Sa 08:47, Magnus Hagander wrote:
>
> On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
>
> On 2023-04-22 Sa 04:50, Michael Paquier wrote:
>
> On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
>
> For 2 the
On Sun, 23 Apr 2023 at 17:16, Tom Lane wrote:
> I think we could go ahead and commit the perltidyrc and README changes
> now. But the ensuing reformatting should happen as part of the mass
> pgindent run, probably next month sometime.
I think it's better to make the changes close together, not
Andrew Dunstan writes:
> On 2023-04-22 Sa 15:58, Tom Lane wrote:
>> Cool, let's use perltidy 20230309 then.
> OK, so when would we do this? The change to 20230309 + valign changes is
> fairly large:
I think we could go ahead and commit the perltidyrc and README changes
now. But the ensuing
On 2023-04-22 Sa 16:15, Tom Lane wrote:
Noah Misch writes:
- skip if the break-glass "pgindent: no" appears in a commit message
There are two things that bother me about putting this functionality
into a server hook, beyond the possible speed issue:
* The risk of failure. I don't have a
On 2023-04-22 Sa 15:58, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-04-22 Sa 11:37, Tom Lane wrote:
* I see that there's now a 20230309 release, should we consider that
instead?
A test I just ran gave identical results to those from 20221112
Cool, let's use perltidy 20230309 then.
On Sat, Apr 22, 2023 at 04:15:23PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > - skip if the break-glass "pgindent: no" appears in a commit message
>
> There are two things that bother me about putting this functionality
> into a server hook, beyond the possible speed issue:
>
> * The risk
Noah Misch writes:
> - skip if the break-glass "pgindent: no" appears in a commit message
There are two things that bother me about putting this functionality
into a server hook, beyond the possible speed issue:
* The risk of failure. I don't have a terribly difficult time imagining
situations
(Given that another commentator is "absolutely against" a hook, this message
is mostly for readers considering this for other projects.)
On Sat, Apr 22, 2023 at 03:23:59PM +0200, Magnus Hagander wrote:
> On Tue, Feb 7, 2023 at 5:43 AM Noah Misch wrote:
> > On Mon, Feb 06, 2023 at 06:17:02PM
Andrew Dunstan writes:
> On 2023-04-22 Sa 11:37, Tom Lane wrote:
>> * I see that there's now a 20230309 release, should we consider that
>> instead?
> A test I just ran gave identical results to those from 20221112
Cool, let's use perltidy 20230309 then.
> The great advantage of not doing this
On 2023-04-22 Sa 11:37, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-04-22 Sa 10:39, Tom Lane wrote:
Another obstacle in the way of (1) is that there was some discussion
of changing perltidy version and/or options. But I don't believe
we have a final proposal on that, much less committed
Andrew Dunstan writes:
> On 2023-04-22 Sa 10:39, Tom Lane wrote:
>> Another obstacle in the way of (1) is that there was some discussion
>> of changing perltidy version and/or options. But I don't believe
>> we have a final proposal on that, much less committed code.
> Well, I posted a fairly
On 2023-04-22 Sa 10:39, Tom Lane wrote:
Another obstacle in the way of (1) is that there was some discussion
of changing perltidy version and/or options. But I don't believe
we have a final proposal on that, much less committed code.
Well, I posted a fairly concrete suggestion with an
Jelte Fennema writes:
> I think there's two things needed to actually start doing this:
> 1. We need to reindent the tree to create an indented baseline
As far as (1) goes, I've been holding off on that because there
are some large patches that still seem in danger of getting
reverted, notably
Magnus Hagander writes:
> On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
>> For 2 the upstream thread listed two approaches:
>> a. Install a pre-receive git hook on the git server that rejects
>> pushes to master that are not indented
>> b. Add a test suite that checks if the code is
On 2023-04-22 Sa 08:47, Magnus Hagander wrote:
On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
On 2023-04-22 Sa 04:50, Michael Paquier wrote:
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
For 2 the upstream thread listed two approaches:
a. Install a pre-receive git
On Tue, Feb 7, 2023 at 5:43 AM Noah Misch wrote:
>
> On Mon, Feb 06, 2023 at 06:17:02PM +0100, Peter Eisentraut wrote:
> > Also, pgindent takes tens of seconds to run, so hooking that into the git
> > push process would slow this down quite a bit.
>
> The pre-receive hook would do a full pgindent
On Sat, Apr 22, 2023 at 1:42 PM Andrew Dunstan wrote:
>
>
> On 2023-04-22 Sa 04:50, Michael Paquier wrote:
>
> On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
>
> For 2 the upstream thread listed two approaches:
> a. Install a pre-receive git hook on the git server that rejects
>
On Sat, Apr 22, 2023 at 07:42:36AM -0400, Andrew Dunstan wrote:
> Perhaps we should start with a buildfarm module, which would run pg_indent
> --show-diff.
Nice, I didn't know this one and it has been mentioned a bit on this
thread. Indeed, it is possible to just rely on that.
--
Michael
On 2023-04-22 Sa 04:50, Michael Paquier wrote:
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
For 2 the upstream thread listed two approaches:
a. Install a pre-receive git hook on the git server that rejects
pushes to master that are not indented
b. Add a test suite that checks
On Fri, Apr 21, 2023 at 09:58:17AM +0200, Jelte Fennema wrote:
> For 2 the upstream thread listed two approaches:
> a. Install a pre-receive git hook on the git server that rejects
> pushes to master that are not indented
> b. Add a test suite that checks if the code is correctly indented, so
>
Now that the PG16 feature freeze happened I think it's time to bump
this thread again. As far as I remember everyone that responded (even
previously silent people) were themselves proponents of being more
strict around pgindent.
I think there's two things needed to actually start doing this:
1.
On 2023-02-16 Th 03:26, shiy.f...@fujitsu.com wrote:
On Thu, Feb 9, 2023 6:10 AM Andrew Dunstan wrote:
Thanks, I have committed this. Still looking at Robert's other request.
Hi,
Commit #068a243b7 supported directories to be non-option arguments of pgindent.
But the help text doesn't
On Thu, Feb 9, 2023 6:10 AM Andrew Dunstan wrote:
> Thanks, I have committed this. Still looking at Robert's other request.
>
Hi,
Commit #068a243b7 supported directories to be non-option arguments of pgindent.
But the help text doesn't mention that. Should we update it? Attach a small
patch
On Wed, Feb 15, 2023 at 12:45:52PM -0600, Justin Pryzby wrote:
> On Mon, Feb 13, 2023 at 07:57:25AM -0500, Andrew Dunstan wrote:
> > On 2023-02-12 Su 15:59, Justin Pryzby wrote:
> > > It seems like if pgindent knows about git, it ought to process only
> > > tracked files. Then, it wouldn't need
> Also, it makes a more sense to "add" the file before indenting it, to
> allow checking the output and remove unrelated changes. So that doesn't
> seem to me like a restriction of any significance.
For my workflow it would be the same, but afaik there's two ways that
people commonly use git
On Mon, Feb 13, 2023 at 07:57:25AM -0500, Andrew Dunstan wrote:
>
> On 2023-02-12 Su 15:59, Justin Pryzby wrote:
> > It seems like if pgindent knows about git, it ought to process only
> > tracked files. Then, it wouldn't need to manually exclude generated
> > files, and it wouldn't process
> (ITYM "remove as many hurdles as possible").
yes, I messed up rewriting that sentence from "having as few hurdles
as possible" to "removing as many hurdles as possible"
> So far, we have had the following categories suggested: dirty, staged,
> dirty+staged, untracked. Are there any others?
On 2023-02-13 Mo 13:29, Jelte Fennema wrote:
On Mon, 13 Feb 2023 at 17:47, Andrew Dunstan wrote:
OK, but I'd like to hear from more people about what they want. Experience
tells me that making assumptions about how people work is not a good idea. I
doubt anyone's work pattern is like mine.
On Mon, 13 Feb 2023 at 17:47, Andrew Dunstan wrote:
> OK, but I'd like to hear from more people about what they want. Experience
> tells me that making assumptions about how people work is not a good idea. I
> doubt anyone's work pattern is like mine. I don't want to implement an option
> that
On 2023-02-13 Mo 09:02, Jelte Fennema wrote:
On Sun, 12 Feb 2023 at 15:16, Andrew Dunstan wrote:
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.
On Sun, 12 Feb 2023 at 15:16, Andrew Dunstan wrote:
> 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]
On 2023-02-12 Su 16:13, Tom Lane wrote:
Andrew Dunstan writes:
On 2023-02-12 Su 11:24, Tom Lane wrote:
It seems like "indent the whole tree" is about to become a minority
use-case. Maybe instead of continuing to privilege that case, we
should say that it's invoked by some new switch like
On 2023-02-12 Su 15:59, Justin Pryzby wrote:
It seems like if pgindent knows about git, it ought to process only
tracked files. Then, it wouldn't need to manually exclude generated
files, and it wouldn't process vpath builds and who-knows-what else it
finds in CWD.
for vpath builds use an
Andrew Dunstan writes:
> On 2023-02-12 Su 11:24, Tom Lane wrote:
>> It seems like "indent the whole tree" is about to become a minority
>> use-case. Maybe instead of continuing to privilege that case, we
>> should say that it's invoked by some new switch like --all-files,
>> and without that
On Sun, Feb 12, 2023 at 11:24:14AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > ... 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
> >
On 2023-02-12 Su 11:24, Tom Lane wrote:
Andrew Dunstan writes:
... 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.
It seems like "indent the
Andrew Dunstan writes:
> ... 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.
It seems like "indent the whole tree" is about to become a
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
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
On 2023-02-07 Tu 11:32, Jelte Fennema wrote:
On Tue, 7 Feb 2023 at 17:11, Robert Haas wrote:
I don't know if that works or not, but it does seem plausible, at
least. My idea would have been to use the --name-status option, which
works for both git diff and git show. You just look and see
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.
On Fri, 10 Feb 2023 at
On Thu, Feb 9, 2023 6:10 AM Andrew Dunstan wrote:
> Thanks, I have committed this. Still looking at Robert's other request.
>
Hi,
I tried the new option --commit and found that it seems to try to indent files
which are deleted in the specified commit and reports an error.
cannot open file
On 2023-02-08 We 21:29, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
Hi,
I tried the committed pgindent.
The attached small patch changes spaces in the usage message to tabs.
Options other than --commit start with a tab.
Thanks, pushed.
cheers
andrew
--
Andrew Dunstan
Pryzby ; Andres Freund ; Noah Misch
; Peter Geoghegan ; Bruce Momjian
; Magnus Hagander ; Alvaro Herrera
; Stephen Frost ; Jesse Zhang
; pgsql-hack...@postgresql.org
Subject: Re: run pgindent on a regular basis / scripted manner
On 2023-02-08 We 12:06, Jelte Fennema wrote:
With the new
On 2023-02-08 We 12:06, Jelte Fennema wrote:
With the new patch --commit works as expected for me now. And sounds
good to up the script a bit afterwards.
Thanks, I have committed this. Still looking at Robert's other request.
cheers
andrew
--
Andrew Dunstan
With the new patch --commit works as expected for me now. And sounds
good to up the script a bit afterwards.
On Wed, 8 Feb 2023 at 14:27, Andrew Dunstan wrote:
>
>
> On 2023-02-08 We 07:41, Andrew Dunstan wrote:
>
>
> On 2023-02-07 Tu 12:21, Jelte Fennema wrote:
>
>
> Does the code-base flag
On 2023-02-08 We 07:41, Andrew Dunstan wrote:
On 2023-02-07 Tu 12:21, Jelte Fennema wrote:
Does the code-base flag still make sense if you can simply pass a
directory as regular args now?
Probably not. I'll look into removing it.
What we should probably do is remove all the build
On 2023-02-07 Tu 12:21, Jelte Fennema wrote:
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
Here's a quick patch for 1 and 3. Would also need to adjust the docco.
This time with patch.
When supplying the --commit flag it still formats all files for me. I
was able to fix that by
> On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
>
> Here's a quick patch for 1 and 3. Would also need to adjust the docco.
>
>
>
> This time with patch.
When supplying the --commit flag it still formats all files for me. I
was able to fix that by replacing:
# no non-option arguments
On Tue, Feb 7, 2023 at 11:32 AM Jelte Fennema wrote:
> On Tue, 7 Feb 2023 at 17:11, Robert Haas wrote:
> > I don't know if that works or not, but it does seem plausible, at
> > least. My idea would have been to use the --name-status option, which
> > works for both git diff and git show. You
On Tue, 7 Feb 2023 at 17:11, Robert Haas wrote:
> I don't know if that works or not, but it does seem plausible, at
> least. My idea would have been to use the --name-status option, which
> works for both git diff and git show. You just look and see which
> lines in the output start with M or A
On Tue, Feb 7, 2023 at 8:17 AM Andrew Dunstan wrote:
> My git-fu is probably not all that it should be. I think we could possibly
> get at this list of files by running
>
> git status --porcelain --untracked-files=no --ignored=no -- .
>
> And then your --dirty list would be lines beginning
Justin Pryzby writes:
> On Sat, Feb 04, 2023 at 12:37:11PM -0500, Tom Lane wrote:
>> But it's not clear to me why you're allergic to the perl wrapper?
> My allergy is to the totality of the process, not to the perl component.
> It's a bit weird to enforce a coding style that no upstream indent
On 2023-02-07 Tu 10:25, Justin Pryzby wrote:
On Sat, Feb 04, 2023 at 12:37:11PM -0500, Tom Lane wrote:
Justin Pryzby writes:
Hmmm ... inserting all of those as the default options would likely
make it impossible to update pg_bsd_indent itself with anything like
its current indent style (not
On Sat, Feb 04, 2023 at 12:37:11PM -0500, Tom Lane wrote:
> Justin Pryzby writes:
> Hmmm ... inserting all of those as the default options would likely
> make it impossible to update pg_bsd_indent itself with anything like
> its current indent style (not that it's terribly consistent about
>
Amit Kapila writes:
> On Tue, Feb 7, 2023 at 5:16 PM Andrew Dunstan wrote:
>> On 2023-02-06 Mo 23:43, Noah Misch wrote:
Yeah. I don't think we are seriously considering putting any restrictions
in place on gitmaster
>>> I could have sworn that was exactly what we were discussing, a
On 2023-02-07 Tu 07:59, Magnus Hagander wrote:
On Tue, Feb 7, 2023 at 1:56 PM Amit Kapila
wrote:
On Tue, Feb 7, 2023 at 5:16 PM Andrew Dunstan
wrote:
>
> On 2023-02-06 Mo 23:43, Noah Misch wrote:
>
>
> Well, we did talk about adding a pre-commit hook to the
On 2023-02-06 Mo 09:40, Robert Haas wrote:
2. I'd like an easy way to indent the unstaged files in the current
directory (e.g. pgindent --dirty) or the files that have been queued
up for commit (e.g. pgindent --cached).
My git-fu is probably not all that it should be. I think we could
On Tue, Feb 7, 2023 at 1:56 PM Amit Kapila wrote:
> On Tue, Feb 7, 2023 at 5:16 PM Andrew Dunstan wrote:
> >
> > On 2023-02-06 Mo 23:43, Noah Misch wrote:
> >
> >
> > Well, we did talk about adding a pre-commit hook to the repository, with
> > instructions for how to enable it. And I don't see
On Tue, Feb 7, 2023 at 5:16 PM Andrew Dunstan wrote:
>
> On 2023-02-06 Mo 23:43, Noah Misch wrote:
>
>
> Well, we did talk about adding a pre-commit hook to the repository, with
> instructions for how to enable it. And I don't see a problem with adding the
> pre-receive we're discussing here to
On 2023-02-06 Mo 23:43, Noah Misch wrote:
Well, we did talk about adding a pre-commit hook to the repository, with
instructions for how to enable it. And I don't see a problem with adding the
pre-receive we're discussing here to src/tools/something.
Yeah. I don't think we are seriously
On Mon, Feb 06, 2023 at 06:17:02PM +0100, Peter Eisentraut wrote:
> Also, pgindent takes tens of seconds to run, so hooking that into the git
> push process would slow this down quite a bit.
The pre-receive hook would do a full pgindent when you change typedefs.list.
Otherwise, it would reindent
Andres Freund writes:
> On 2023-02-06 18:17:02 +0100, Peter Eisentraut wrote:
>> First, as a matter of principle, it would introduce another level of
>> gatekeeping power. Right now, the committers are as a group in charge of
>> what gets into the tree. Adding commit hooks that are installed
>>
Hi,
On 2023-02-06 18:17:02 +0100, Peter Eisentraut wrote:
> First, as a matter of principle, it would introduce another level of
> gatekeeping power. Right now, the committers are as a group in charge of
> what gets into the tree. Adding commit hooks that are installed
> somewhere(?) by
On 2023-02-06 Mo 12:17, Peter Eisentraut wrote:
On 02.02.23 07:40, Tom Lane wrote:
Noah Misch writes:
Regarding the concern about a pre-receive hook blocking an emergency
push, the
hook could approve every push where a string like "pgindent: no"
appears in a
commit message within the push.
On 2023-02-06 Mo 12:03, Andrew Dunstan wrote:
On 2023-02-06 Mo 10:36, Robert Haas wrote:
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
Good suggestions. 1 and 3 seem fairly straightforward. I'll start on those, and
look into 2.
Thanks!
Here's a quick patch for 1 and 3. Would
On 02.02.23 07:40, Tom Lane wrote:
Noah Misch writes:
Regarding the concern about a pre-receive hook blocking an emergency push, the
hook could approve every push where a string like "pgindent: no" appears in a
commit message within the push. You'd still want to make the tree clean
sometime
On 2023-02-06 Mo 10:36, Robert Haas wrote:
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
Good suggestions. 1 and 3 seem fairly straightforward. I'll start on those, and
look into 2.
Thanks!
Here's a quick patch for 1 and 3. Would also need to adjust the docco.
cheers
andrew
On Mon, Feb 6, 2023 at 10:21 AM Andrew Dunstan wrote:
> Good suggestions. 1 and 3 seem fairly straightforward. I'll start on those,
> and look into 2.
Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Feb 6, 2023 at 10:16 AM Tom Lane wrote:
> I'll just note that adding features like those to a Perl script
> is going to be a ton easier than doing it inside pg_bsd_indent.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 2023-02-06 Mo 09:40, Robert Haas wrote:
On Sat, Feb 4, 2023 at 12:37 PM Tom Lane wrote:
But it's not clear to me why you're allergic to the perl wrapper?
It's not like that's the only perl infrastructure in our build process.
Also, whether or not we could push some of what it does into
Robert Haas writes:
> I don't mind that there is a script. I do mind that it's not that good
> of a script. There have been some improvements for which I am
> grateful, like removing the thing where the first argument was taken
> as a typedefs file under some circumstances. But there are still
On Sat, Feb 4, 2023 at 12:37 PM Tom Lane wrote:
> But it's not clear to me why you're allergic to the perl wrapper?
> It's not like that's the only perl infrastructure in our build process.
> Also, whether or not we could push some of what it does into pg_bsd_indent
> proper, I can't see pushing
On 2023-02-04 Sa 09:20, Andrew Dunstan wrote:
On 2023-02-04 Sa 06:34, Andres Freund wrote:
ISTM that we're closer to being able to enforce pgindent than
perltidy. At the same time, I think the issue of C code in HEAD not
being indented is more pressing - IME it's much more common to have to
Justin Pryzby writes:
> Would you want to make those the default options of the in-tree indent ?
> Or provide a shortcut like --postgresql ?
Hmmm ... inserting all of those as the default options would likely
make it impossible to update pg_bsd_indent itself with anything like
its current indent
On Sat, Feb 04, 2023 at 11:07:59AM -0500, Tom Lane wrote:
> (I haven't forgotten that I'm on the hook to import pg_bsd_indent
> into our tree. Will get to that soon.)
+1 for that - it's no surprise that you have trouble convincing people
to follow the current process:
1) requires using a hacked
Andres Freund writes:
> ISTM that we're closer to being able to enforce pgindent than
> perltidy. At the same time, I think the issue of C code in HEAD not
> being indented is more pressing - IME it's much more common to have to
> touch a lot of C code than to have to touch a lot fo perl files.
On 2023-02-04 Sa 06:34, Andres Freund wrote:
ISTM that we're closer to being able to enforce pgindent than
perltidy. At the same time, I think the issue of C code in HEAD not
being indented is more pressing - IME it's much more common to have to
touch a lot of C code than to have to touch a
Hi,
On 2023-02-03 20:18:48 -0800, Noah Misch wrote:
> On Fri, Feb 03, 2023 at 12:52:50PM -0500, Tom Lane wrote:
> > Andrew Dunstan writes:
> > > On 2023-01-22 Su 17:47, Tom Lane wrote:
> > >> Yeah. That's one of my biggest gripes about pgperltidy: if you insert
> > >> another assignment in a
On Fri, Feb 03, 2023 at 12:52:50PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2023-01-22 Su 17:47, Tom Lane wrote:
> >> Yeah. That's one of my biggest gripes about pgperltidy: if you insert
> >> another assignment in a series of assignments, it is very likely to
> >> reformat all the
On Thu, Feb 02, 2023 at 11:34:37AM +, Dean Rasheed wrote:
> I didn't reply until now, but I'm solidly in the camp of committers
> who care about keeping the tree properly indented, and I wouldn't have
> any problem with such a check being imposed.
So do I. pgindent is part of my routine when
Andrew Dunstan writes:
> On 2023-01-22 Su 17:47, Tom Lane wrote:
>> Yeah. That's one of my biggest gripes about pgperltidy: if you insert
>> another assignment in a series of assignments, it is very likely to
>> reformat all the adjacent assignments because it thinks it's cool to
>> make all the
On 2023-01-22 Su 17:47, Tom Lane wrote:
Andres Freund writes:
I strongly dislike it, I rarely get it right by hand - but it does have some
benefit over aligning variable names based on the length of the type names as
uncrustify/clang-format: In their approach an added local variable can cause
On 2023-02-02 Th 10:00, Tom Lane wrote:
> Andrew Dunstan writes:
>> Sure. There's probably some work that could still be done in this area
>> too, such as making pgperltidy work similarly to how we've now make
>> pgindent work.
> Perhaps. But before we commit to that, I'd like to see some
Andrew Dunstan writes:
> Sure. There's probably some work that could still be done in this area
> too, such as making pgperltidy work similarly to how we've now make
> pgindent work.
Perhaps. But before we commit to that, I'd like to see some tweaks to the
pgperltidy rules to make it less eager
On 2023-02-02 Th 01:40, Tom Lane wrote:
> Noah Misch writes:
>> Regarding the concern about a pre-receive hook blocking an emergency push,
>> the
>> hook could approve every push where a string like "pgindent: no" appears in a
>> commit message within the push. You'd still want to make the
On Thu, Feb 2, 2023 at 5:05 PM Dean Rasheed wrote:
>
> On Thu, 2 Feb 2023 at 06:40, Tom Lane wrote:
> >
> > Noah Misch writes:
> > > Regarding the concern about a pre-receive hook blocking an emergency
> > > push, the
> > > hook could approve every push where a string like "pgindent: no"
On Fri, Feb 3, 2023 at 12:35 AM Dean Rasheed wrote:
> And as someone who runs pgindent regularly, I think this will be a net
> time saver, since I won't have to skip over other unrelated indent
> changes all the time.
+1
On Thu, 2 Feb 2023 at 06:40, Tom Lane wrote:
>
> Noah Misch writes:
> > Regarding the concern about a pre-receive hook blocking an emergency push,
> > the
> > hook could approve every push where a string like "pgindent: no" appears in
> > a
> > commit message within the push. You'd still want
Noah Misch writes:
> Regarding the concern about a pre-receive hook blocking an emergency push, the
> hook could approve every push where a string like "pgindent: no" appears in a
> commit message within the push. You'd still want to make the tree clean
> sometime the same week or so. It's
On Mon, Jan 30, 2023 at 03:42:09PM -0500, Bruce Momjian wrote:
> On Sat, Jan 28, 2023 at 05:06:03PM -0800, Noah Misch wrote:
> > On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote:
> > > On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote:
> > > > As another example, the mechanisms
On Sat, Jan 28, 2023 at 05:06:03PM -0800, Noah Misch wrote:
> On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote:
> > On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote:
> > > As another example, the mechanisms we use to create the typedefs list
> > > in the first place are pretty
Noah Misch writes:
> Yes, a hook intended to enforce pgindent cleanliness should run tree-wide
> pgindent when the given commit(s) change the typedef list. typedef list
> changes essentially become another kind of refactoring that can yield merge
> conflicts. If your commit passed the pgindent
On Tue, Jan 24, 2023 at 02:04:02PM -0500, Bruce Momjian wrote:
> On Tue, Jan 24, 2023 at 09:54:57AM -0500, Tom Lane wrote:
> > As another example, the mechanisms we use to create the typedefs list
> > in the first place are pretty squishy/leaky: they depend on which
> > buildfarm animals are
On 2023-01-26 Th 17:54, Jelte Fennema wrote:
>
>> I'm still mildly inclined to say this material would be better placed
>> in the developer wiki. After all, this isn't the only thing a postgres
>> developer might use a git hook for
> I think it should definitely be somewhere. I have a
101 - 200 of 308 matches
Mail list logo
