Re: run pgindent on a regular basis / scripted manner

On 2023-10-28 Sa 12:09, Tom Lane wrote: Andrew Dunstan writes: Based on recent experience, where a lot koel's recent complaints seem to be about comments, I'd like to suggest a modest adjustment. First, we should provide a mode of pgindent that doesn't reflow comments. pg_bsd_indent has a

Re: run pgindent on a regular basis / scripted manner

Andrew Dunstan writes: > Based on recent experience, where a lot koel's recent complaints seem to > be about comments, I'd like to suggest a modest adjustment. > First, we should provide a mode of pgindent that doesn't reflow > comments. pg_bsd_indent has a flag for this (-nfcb), so this

Re: run pgindent on a regular basis / scripted manner

On 2023-08-12 Sa 11:57, Andrew Dunstan wrote: On 2023-08-11 Fr 19:17, Tom Lane wrote: Peter Geoghegan writes: I'm starting to have doubts about this policy. There have now been quite a few follow-up "fixes" to indentation issues that koel complained about. None of these fixups have been

Re: run pgindent on a regular basis / scripted manner

On 2023-10-27 Fr 03:14, Étienne BERSAC wrote: Hello, Yes, there's a lot to look out for, and you're a damn sight better at it than I am. But we should try to automate the things that can be automated, even if that leaves many tasks that can't be. I have three things in my pre-commit hook: a

Re: run pgindent on a regular basis / scripted manner

Hello, > Yes, there's a lot to look out for, and you're a damn sight better at > it > than I am. But we should try to automate the things that can be > automated, even if that leaves many tasks that can't be. I have three > things in my pre-commit hook: a check for catalog updates, a check >

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 24, 2023 at 6:21 AM Jeff Davis wrote: > > On Wed, 2023-10-18 at 22:34 +1300, David Rowley wrote: > > It would be good to learn how many of the committers out of the ones > > you listed that --enable-indent-checks would have saved from breaking > > koel. > > I'd find that a useful

Re: run pgindent on a regular basis / scripted manner

On 2023-10-18 We 05:07, Jelte Fennema wrote: I think --enable-indent-checks sounds like a good improvement to the status quo. But I'm not confident that it will help remove the cases where only a comment needs to be re-indented. Do commiters really always run check-world again when only

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 24, 2023 at 09:40:01AM -0400, Andrew Dunstan wrote: > Slightly off topic, but apropos your message, maybe we should recommend a > standard git commit template. I use this and then automatically remove any sections that are empty.

Re: run pgindent on a regular basis / scripted manner

On 2023-10-17 Tu 09:52, Robert Haas wrote: On Tue, Oct 17, 2023 at 6:34 AM Jelte Fennema wrote: I think *it is* dead easy to comply. If you run the following commands before committing/after rebasing, then koel should always be happy: src/tools/pgindent/pgindent src # works always but a bit

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 24, 2023 at 10:16:55AM +0900, Amit Langote wrote: > +1. While I’ve made it part of routine to keep my local work pgindented > since breaking Joel once, an option like this would still be useful. I'd be OK with an option like that. It is one of these things to type once in a script,

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 24, 2023 at 9:51 Jeff Davis wrote: > On Wed, 2023-10-18 at 22:34 +1300, David Rowley wrote: > > It would be good to learn how many of the committers out of the ones > > you listed that --enable-indent-checks would have saved from breaking > > koel. > > I'd find that a useful option.

Re: run pgindent on a regular basis / scripted manner

On Wed, 2023-10-18 at 22:34 +1300, David Rowley wrote: > It would be good to learn how many of the committers out of the ones > you listed that --enable-indent-checks would have saved from breaking > koel. I'd find that a useful option. Regards, Jeff Davis

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-10-18 19:18:13 -0700, Andres Freund wrote: > On 2023-10-18 21:29:37 -0400, Tom Lane wrote: > Ah, I see. If I interpret that correctly, the code filters out symbols it > doesn't find in in some .[chly] file in the *source* directory. This code is, > uh, barely readable and massively

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-10-18 21:29:37 -0400, Tom Lane wrote: > Andres Freund writes: > > It turns out that updating the in-tree typedefs.list would be very noisy. On > > my local linux system I get > > 1 file changed, 422 insertions(+), 1 deletion(-) > > On a mac mini I get > > 1 file changed, 351

Re: run pgindent on a regular basis / scripted manner

Andres Freund writes: > It turns out that updating the in-tree typedefs.list would be very noisy. On > my local linux system I get > 1 file changed, 422 insertions(+), 1 deletion(-) > On a mac mini I get > 1 file changed, 351 insertions(+), 1 deletion(-) That seems like it needs a considerably

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-10-18 12:15:51 -0700, Andres Freund wrote: > I still think that one of the more important things we ought to do is to make > it trivial to check if code is correctly indented and reindent it for the > user. I've posted a preliminary patch to add a 'indent-tree' target a few > months

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-10-16 20:45:00 -0400, Tom Lane wrote: > Peter Geoghegan writes: > 2. We could raise awareness of this issue by adding indent verification > to CI testing. I hesitate to suggest that, though, for a couple of > reasons: >2a. It seems fairly expensive, though I might be misjudging.

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 11:01:44AM -0400, Robert Haas wrote: > In fact, that particular experience is one of the worst things about > being a committer. It actively discourages me, at least, from trying > to get other people's patches committed. This particular problem is > minor, but the overall

Re: run pgindent on a regular basis / scripted manner

On Wed, Oct 18, 2023 at 3:21 AM Peter Eisentraut wrote: > On 18.10.23 06:40, David Rowley wrote: > > I agree that it's not nice to add yet another way of breaking the > > buildfarm and even more so when the committer did make check-world > > before committing. We have --enable-tap-tests, we could

Re: run pgindent on a regular basis / scripted manner

On 10/17/23 16:23, Tom Lane wrote: An alternative I was thinking about after reading your earlier email was going back to the status quo ante, but doing the manual tree-wide reindents significantly more often than once a year. Adding one at the conclusion of each commitfest would be a natural

Re: run pgindent on a regular basis / scripted manner

On Wed, 18 Oct 2023 at 22:07, Jelte Fennema wrote: > But based on the contents of the fixup commits a commonality seems to > be that the fixup only fixes a few lines, quite often touching only > comments. So it seems like the main reason for breaking koel is > forgetting to re-run pgindent after

Re: run pgindent on a regular basis / scripted manner

On Wed, 18 Oct 2023 at 06:40, David Rowley wrote: > How many of the committers who have broken koel are repeat offenders? I just checked the commits and there don't seem to be real repeat offenders. The maximum number of times someone broke koel since its inception is two. That was the case for

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 23:01, Magnus Hagander wrote: > And unless we're only enforcing it on master, we'd also need to make > provisions for different versions of it on different branches, I > think? Only enforcing on master sounds fine to me, that's what koel is doing too afaik. In practice

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 11:07 PM Tom Lane wrote: > > Magnus Hagander writes: > > If it doesn't know how to rebuild it, aren't we going to be stuck in a > > catch-22 if we need to change it in certain ways? Since an old version > > of pg_bsd_indent would reject the patch that might include

Re: run pgindent on a regular basis / scripted manner

On 18.10.23 06:40, David Rowley wrote: I agree that it's not nice to add yet another way of breaking the buildfarm and even more so when the committer did make check-world before committing. We have --enable-tap-tests, we could have --enable-indent-checks and have pgindent check the code is

Re: run pgindent on a regular basis / scripted manner

On Wed, 18 Oct 2023 at 01:47, Robert Haas wrote: > On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote: > > This policy isn't working. > > +1. I think this is more annoying than the status quo ante. Maybe there are two camps of committers here; ones who care about committing correctly

Re: run pgindent on a regular basis / scripted manner

Magnus Hagander writes: > If it doesn't know how to rebuild it, aren't we going to be stuck in a > catch-22 if we need to change it in certain ways? Since an old version > of pg_bsd_indent would reject the patch that might include updating > it. (And when it does, one should expect the push to

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 10:43 PM Jelte Fennema wrote: > > On Tue, 17 Oct 2023 at 18:53, Maciek Sakrejda wrote: > > Git push does have an --atomic flag to treat the entire push as a single > > operation. > > I decided to play around a bit with server hooks. Attached is a git > "update" hook that

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 18:53, Maciek Sakrejda wrote: > Git push does have an --atomic flag to treat the entire push as a single > operation. I decided to play around a bit with server hooks. Attached is a git "update" hook that rejects pushes to the master branch when the new HEAD of master

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023, 09:22 Robert Haas wrote: > On Tue, Oct 17, 2023 at 12:18 PM Tom Lane wrote: > > Robert Haas writes: > > Is that actually possible? I had the idea that "git push" is an > > atomic operation, ie 100% or nothing. Is it only atomic per-branch? > > I believe so. Git push

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 12:18 PM Tom Lane wrote: > Robert Haas writes: > > One potential problem with a server-side hook is that if you back-port > > a commit to older branches and then push the commits all together > > (which is my workflow) then you might get failure to push on some > >

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 12:17 PM Tom Lane wrote: > Hmm, I've not found it that hard to manage the typedefs list. > If I run pgindent and it adds weird spacing around uses of a new > typedef name, I go "oh, I better add that to the list" and do so. > End of problem. There's not a requirement that

Re: run pgindent on a regular basis / scripted manner

Robert Haas writes: > One potential problem with a server-side hook is that if you back-port > a commit to older branches and then push the commits all together > (which is my workflow) then you might get failure to push on some > branches but not others. I don't know if there's any way to avoid

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > That's beside the point. The point is that I'm obligated to keep > typedef.list up to date in general, a task that is made significantly > harder by random objdump implementation details. And I probably need > to do this not just once per commit, but several times, since

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 9:03 AM Jelte Fennema wrote: > To make koel pass you don't need to worry about hand-polishing > typedefs.list. koel uses the typedefs.list that's committed into the > repo, just like when you run pgindent yourself. If you forget to > update the typedefs.list with new

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 17:47, Peter Geoghegan wrote: > Once you figure all that out, you're still obligated to hand-polish > typedefs.list to be consistent with whatever Bruce's machine's copy of > objdump does (or is it Tom's?). You need to sort the entries so they > kinda look like they

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 8:24 AM Robert Haas wrote: > I also just discovered that my pre-commit hook doesn't work if I pull > commits into master by cherry-picking. I had thought that I could have > my hook just check my commits to master and not all of my local dev > branches where I really don't

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 11:23 AM Jelte Fennema wrote: > To clarify, I did not intend to imply people that commit unindented > code are lazy. It's expected that humans forget to run pgindent before > committing from time to time (I do too). That's why I proposed a > server side git hook to reject

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 11:16 AM Peter Geoghegan wrote: > Yep. Enforcing perfect indentation on koel necessitates rechecking > indentation after each and every last-minute fixup affecting C code -- > the interactions makes it quite a bit harder to get everything right > on the first push. For

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 16:04, Robert Haas wrote: > What I really dislike about the current situation is that > it's doubling down on the idea that committers have to be perfect and > get everything right every time. Turns out, that's hard to do. If not, > why do people keep screwing things up?

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 8:01 AM Robert Haas wrote: > In fact, that particular experience is one of the worst things about > being a committer. It actively discourages me, at least, from trying > to get other people's patches committed. This particular problem is > minor, but the overall

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 10:23 AM Tom Lane wrote: > An alternative I was thinking about after reading your earlier email > was going back to the status quo ante, but doing the manual tree-wide > reindents significantly more often than once a year. Adding one at > the conclusion of each commitfest

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 16:23, Tom Lane wrote: > > Or we could have a server-side hook that will refuse > > the misindented commit, with some kind of override for emergency > > situations. > > Even though I'm in the camp that would like the tree correctly > indented at all times, I remain very

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 7:23 AM Tom Lane wrote: > Robert Haas writes: > > On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote: > >> +1. I think this is more annoying than the status quo ante. > > > Although ... I do think it's spared me some rebasing pain, and that > > does have some real value.

Re: run pgindent on a regular basis / scripted manner

Robert Haas writes: > On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote: >> +1. I think this is more annoying than the status quo ante. > Although ... I do think it's spared me some rebasing pain, and that > does have some real value. I wonder if we could think of other > alternatives. An

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 8:45 AM Robert Haas wrote: > > This policy isn't working. > > +1. I think this is more annoying than the status quo ante. Although ... I do think it's spared me some rebasing pain, and that does have some real value. I wonder if we could think of other alternatives. For

Re: run pgindent on a regular basis / scripted manner

On Tue, Oct 17, 2023 at 6:34 AM Jelte Fennema wrote: > I think *it is* dead easy to comply. If you run the following commands > before committing/after rebasing, then koel should always be happy: > > src/tools/pgindent/pgindent src # works always but a bit slow > src/tools/pgindent/pgindent $(git

Re: run pgindent on a regular basis / scripted manner

On Sun, Oct 15, 2023 at 8:52 PM Peter Geoghegan wrote: > On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote: > > Maybe I'm wrong -- maybe the new policy is practicable. It might even > > turn out to be worth the bother. Time will tell. > > (Two months pass.) > > There were two independent

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 04:57, Michael Paquier wrote: > I see an extra reason with not doing that: this increases the > difficulty when it comes to send and maintain patches to the lists and > newcomers would need to learn more tooling. I don't think that we > should make that more complicated

Re: run pgindent on a regular basis / scripted manner

On Tue, 17 Oct 2023 at 03:23, Peter Geoghegan wrote: > My main objection to the new policy is that it's not quite clear what > process I should go through in order to be 100% confident that koel > won't start whining (short of waiting around for koel to whine). I > know how to run pgindent, of

Re: run pgindent on a regular basis / scripted manner

On Mon, Oct 16, 2023 at 08:45:00PM -0400, Tom Lane wrote: > 2. We could raise awareness of this issue by adding indent verification > to CI testing. I hesitate to suggest that, though, for a couple of > reasons: >2a. It seems fairly expensive, though I might be misjudging. >2b. It's often

Re: run pgindent on a regular basis / scripted manner

On Mon, Oct 16, 2023 at 6:32 PM Tom Lane wrote: > But it's *not* a hard rule --- we explicitly rejected mechanisms > that would make it so (such as a precommit hook). I view "koel > is unhappy" as something that you ought to clean up, but if you > don't get to it for a day or three there's not

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > My main objection to the new policy is that it's not quite clear what > process I should go through in order to be 100% confident that koel > won't start whining (short of waiting around for koel to whine). I > know how to run pgindent, of course, and haven't had any

Re: run pgindent on a regular basis / scripted manner

On Mon, Oct 16, 2023 at 5:45 PM Tom Lane wrote: > Two thoughts about that: > > 1. We should not commit indent fixups on behalf of somebody else's > misindented commit. Peer pressure on committers who aren't being > careful about this is the only way to improve matters; so complain > to the

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > There were two independent fixup commits to address complaints from > koel just today (from two different committers). Plus there was a > third issue (involving a third committer) this past Wednesday. > This policy isn't working. Two thoughts about that: 1. We should

Re: run pgindent on a regular basis / scripted manner

On Sat, Aug 12, 2023 at 5:53 PM Peter Geoghegan wrote: > Maybe I'm wrong -- maybe the new policy is practicable. It might even > turn out to be worth the bother. Time will tell. (Two months pass.) There were two independent fixup commits to address complaints from koel just today (from two

Re: run pgindent on a regular basis / scripted manner

On Wed, Aug 16, 2023 at 01:15:55PM -0700, Peter Geoghegan wrote: > On Tue, Aug 15, 2023 at 1:31 PM Nathan Bossart > wrote: >> Should we add those? Patch attached. > > I think that that makes sense. Committed. > I just don't want to normalize updating > .git-blame-ignore-revs very frequently.

Re: run pgindent on a regular basis / scripted manner

On Tue, Aug 15, 2023 at 1:31 PM Nathan Bossart wrote: > Should we add those? Patch attached. I think that that makes sense. I just don't want to normalize updating .git-blame-ignore-revs very frequently. (Actually, it's more like I don't want to normalize any scheme that makes updating the

Re: run pgindent on a regular basis / scripted manner

On Fri, Aug 11, 2023 at 01:59:40PM -0700, Peter Geoghegan wrote: > I'm starting to have doubts about this policy. There have now been > quite a few follow-up "fixes" to indentation issues that koel > complained about. None of these fixups have been included in > .git-blame-ignore-revs. If things

Re: run pgindent on a regular basis / scripted manner

On 2023-08-14 Mo 10:04, Peter Eisentraut wrote: On 12.08.23 23:14, Andres Freund wrote: It's a somewhat annoying task though, find all the typedefs, add them to the right place in the file (we have an out of order entry right now). I think a script that*adds*  (but doesn't remove) local

Re: run pgindent on a regular basis / scripted manner

On 12.08.23 02:11, Tom Lane wrote: Andres Freund writes: On 2023-08-11 18:30:02 -0400, Tom Lane wrote: +1 for including this in CI tests I didn't even mean CI - I meant 'make check-world' / 'meson test'. Which of course would include CI automatically. Hmm. I'm allergic to anything that

Re: run pgindent on a regular basis / scripted manner

On 12.08.23 23:14, Andres Freund wrote: It's a somewhat annoying task though, find all the typedefs, add them to the right place in the file (we have an out of order entry right now). I think a script that*adds* (but doesn't remove) local typedefs would make this less painful. I was puzzled

Re: run pgindent on a regular basis / scripted manner

On Sun, Aug 13, 2023 at 10:33:21AM -0400, Andrew Dunstan wrote: > After I'd been caught by this once or twice I implemented a git hook test > for that too - in fact it was the first hook I did. It's not perfect but > it's saved me a couple of times: > > check_catalog_version () { I find that

Re: run pgindent on a regular basis / scripted manner

On 2023-08-12 Sa 20:53, Peter Geoghegan wrote: On Sat, Aug 12, 2023 at 5:20 PM Tom Lane wrote: Hm. I was envisioning that we should expect committers to deal with this, not original patch submitters. So that's an argument against including it in the CI tests. But I'm in favor of anything

Re: run pgindent on a regular basis / scripted manner

On Sat, Aug 12, 2023 at 5:20 PM Tom Lane wrote: > Hm. I was envisioning that we should expect committers to deal > with this, not original patch submitters. So that's an argument > against including it in the CI tests. But I'm in favor of anything > we can do to make it more painless for

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > We seem to be seriously contemplating making every patch author do > this every time they need to get the tests to pass (after adding or > renaming a struct). Is that really an improvement over the old status > quo? Hm. I was envisioning that we should expect

Re: run pgindent on a regular basis / scripted manner

On Sat, Aug 12, 2023 at 3:47 PM Tom Lane wrote: > > It's a somewhat annoying task though, find all the typedefs, add them to the > > right place in the file (we have an out of order entry right now). I think a > > script that *adds* (but doesn't remove) local typedefs would make this less > >

Re: run pgindent on a regular basis / scripted manner

Andres Freund writes: > On 2023-08-12 17:03:37 -0400, Andrew Dunstan wrote: >> My recollection is that missing typedefs cause indentation that kinda sticks >> out like a sore thumb. Yeah, it's usually pretty obvious: "typedef *var" gets changed to "typedef * var", and similar oddities. > It's a

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-08-12 17:03:37 -0400, Andrew Dunstan wrote: > On 2023-08-11 Fr 19:02, Tom Lane wrote: > > Peter Geoghegan writes: > > > My workflow up until now has avoiding making updates to typedefs.list > > > in patches. I only update typedefs locally, for long enough to indent > > > my code. The

Re: run pgindent on a regular basis / scripted manner

On 2023-08-11 Fr 19:02, Tom Lane wrote: Peter Geoghegan writes: My workflow up until now has avoiding making updates to typedefs.list in patches. I only update typedefs locally, for long enough to indent my code. The final patch doesn't retain any typedefs.list changes. Yeah, I've done the

Re: run pgindent on a regular basis / scripted manner

On 2023-08-11 Fr 19:17, Tom Lane wrote: Peter Geoghegan writes: I'm starting to have doubts about this policy. There have now been quite a few follow-up "fixes" to indentation issues that koel complained about. None of these fixups have been included in .git-blame-ignore-revs. If things

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-08-11 20:11:34 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2023-08-11 18:30:02 -0400, Tom Lane wrote: > >> +1 for including this in CI tests > > > I didn't even mean CI - I meant 'make check-world' / 'meson test'. Which of > > course would include CI automatically. > > Hmm.

Re: run pgindent on a regular basis / scripted manner

On Fri, Aug 11, 2023 at 08:11:34PM -0400, Tom Lane wrote: > Hmm. I'm allergic to anything that significantly increases the cost > of check-world, and this seems like it'd do that. > > Maybe we could automate it, but not as part of check-world per se? It does not have to be part of check-world

Re: run pgindent on a regular basis / scripted manner

Andres Freund writes: > On 2023-08-11 18:30:02 -0400, Tom Lane wrote: >> +1 for including this in CI tests > I didn't even mean CI - I meant 'make check-world' / 'meson test'. Which of > course would include CI automatically. Hmm. I'm allergic to anything that significantly increases the cost

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-08-11 18:30:02 -0400, Tom Lane wrote: > Peter Geoghegan writes: > > On Fri, Aug 11, 2023 at 2:25 PM Andres Freund wrote: > >> We could a test that fails when there's some mis-indented code. That seems > >> like it might catch things earlier? > > +1 for including this in CI tests I

Re: run pgindent on a regular basis / scripted manner

On Fri, 11 Aug 2023 at 23:00, Peter Geoghegan wrote: > I'm starting to have doubts about this policy. There have now been > quite a few follow-up "fixes" to indentation issues that koel > complained about. I think one thing that would help a lot in reducing the is for committers to set up the

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > I'm starting to have doubts about this policy. There have now been > quite a few follow-up "fixes" to indentation issues that koel > complained about. None of these fixups have been included in > .git-blame-ignore-revs. If things continue like this then "git blame" > is

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > My workflow up until now has avoiding making updates to typedefs.list > in patches. I only update typedefs locally, for long enough to indent > my code. The final patch doesn't retain any typedefs.list changes. Yeah, I've done the same and will have to stop. > I guess

Re: run pgindent on a regular basis / scripted manner

On Fri, Aug 11, 2023 at 3:30 PM Tom Lane wrote: > No. I presume koel is using src/tools/pgindent/typedefs.list, > which has always been the "canonical" list but up to now we've > been lazy about maintaining it. Part of the new regime is that > typedefs.list should now be updated on-the-fly by

Re: run pgindent on a regular basis / scripted manner

Peter Geoghegan writes: > On Fri, Aug 11, 2023 at 2:25 PM Andres Freund wrote: >> We could a test that fails when there's some mis-indented code. That seems >> like it might catch things earlier? +1 for including this in CI tests > It definitely would. That would go a long way towards

Re: run pgindent on a regular basis / scripted manner

On Fri, Aug 11, 2023 at 2:25 PM Andres Freund wrote: > > I don't think that it makes sense to invent yet another rule for > > .git-blame-ignore-revs, though. Will we need another buildfarm member > > to enforce that rule, too? > > We could a test that fails when there's some mis-indented code.

Re: run pgindent on a regular basis / scripted manner

Hi, On 2023-08-11 13:59:40 -0700, Peter Geoghegan wrote: > On Sat, Jun 17, 2023 at 7:08 AM Andrew Dunstan wrote: > > I have set up a new buildfarm animal called koel which will run the module. > > I'm starting to have doubts about this policy. There have now been > quite a few follow-up "fixes"

Re: run pgindent on a regular basis / scripted manner

On Sat, Jun 17, 2023 at 7:08 AM Andrew Dunstan wrote: > I have set up a new buildfarm animal called koel which will run the module. I'm starting to have doubts about this policy. There have now been quite a few follow-up "fixes" to indentation issues that koel complained about. None of these

Re: run pgindent on a regular basis / scripted manner

On 2023-06-20 Tu 09:08, Tom Lane wrote: Andrew Dunstan writes: On 2023-06-19 Mo 17:07, Tom Lane wrote: Is koel tracking the right repo? It just spit up with a bunch of diffs that seem to have little to do with the commit it's claiming caused them: Yeah, I changed it so that instead of just

Re: run pgindent on a regular basis / scripted manner

Andrew Dunstan writes: > On 2023-06-19 Mo 17:07, Tom Lane wrote: >> Is koel tracking the right repo? It just spit up with a bunch of >> diffs that seem to have little to do with the commit it's claiming >> caused them: > Yeah, I changed it so that instead of just checking new commits it would

Re: run pgindent on a regular basis / scripted manner

On 2023-06-19 Mo 17:07, Tom Lane wrote: Andrew Dunstan writes: I have set up a new buildfarm animal called koel which will run the module. Is koel tracking the right repo? It just spit up with a bunch of diffs that seem to have little to do with the commit it's claiming caused them:

Re: run pgindent on a regular basis / scripted manner

On Sat, Jun 17, 2023 at 10:08:32AM -0400, Andrew Dunstan wrote: > See > > I have set up a new buildfarm animal called koel which will run the module. That's really cool! Thanks for taking the time to do

Re: run pgindent on a regular basis / scripted manner

Andrew Dunstan writes: > I have set up a new buildfarm animal called koel which will run the module. Is koel tracking the right repo? It just spit up with a bunch of diffs that seem to have little to do with the commit it's claiming caused them:

Re: run pgindent on a regular basis / scripted manner

On 2023-06-15 Th 12:12, Andrew Dunstan wrote: On 2023-06-15 Th 11:26, Jelte Fennema wrote: On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote: Perhaps we should start with a buildfarm module, which would run pg_indent --show-diff. That would only need to run on one animal, so a failure

Re: run pgindent on a regular basis / scripted manner

On 2023-06-15 Th 11:26, Jelte Fennema wrote: On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote: Perhaps we should start with a buildfarm module, which would run pg_indent --show-diff. That would only need to run on one animal, so a failure wouldn't send the whole buildfarm red. This would

Re: run pgindent on a regular basis / scripted manner

On Sat, 22 Apr 2023 at 13:42, Andrew Dunstan wrote: > Perhaps we should start with a buildfarm module, which would run pg_indent > --show-diff. That would only need to run on one animal, so a failure wouldn't > send the whole buildfarm red. This would be pretty easy to do. Just to be clear on

Re: run pgindent on a regular basis / scripted manner

On 2023-05-17 We 17:10, Tom Lane wrote: I wrote: Andrew Dunstan writes: I doubt there's something like that. I had a read-through of the latest version's man page, and found this promising-looking entry: -boc, --break-at-old-comma-breakpoints Sadly, this seems completely not ready

Re: run pgindent on a regular basis / scripted manner

I wrote: > Andrew Dunstan writes: >> I doubt there's something like that. > I had a read-through of the latest version's man page, and found > this promising-looking entry: > -boc, --break-at-old-comma-breakpoints Sadly, this seems completely not ready for prime time. I experimented with

Re: run pgindent on a regular basis / scripted manner

Andrew Dunstan writes: > On 2023-04-28 Fr 14:08, Bruce Momjian wrote: >> Can those comments be added by a preprocessor before calling perltidy, >> and then removed on completion? > I imagine so, but we'd need a way of determining algorithmically which > lines to protect. That might not be at

Re: run pgindent on a regular basis / scripted manner

On 2023-04-28 Fr 14:08, Bruce Momjian wrote: On Wed, Apr 26, 2023 at 03:44:47PM -0400, Andrew Dunstan wrote: On 2023-04-26 We 09:27, Tom Lane wrote: I doubt there's something like that. You can freeze arbitrary blocks of code like this (from the manual) #<<<  format skipping: do not let

Re: run pgindent on a regular basis / scripted manner

On 2023-04-28 Fr 05:25, Alvaro Herrera wrote: On 2023-Feb-05, Andrew Dunstan wrote: So here's a diff made from running perltidy v20221112 with the additional setting --valign-exclusion-list=", = => || && if unless" I ran this experimentally with perltidy 20230309, and compared that with the

Re: run pgindent on a regular basis / scripted manner

On Wed, Apr 26, 2023 at 03:44:47PM -0400, Andrew Dunstan wrote: > On 2023-04-26 We 09:27, Tom Lane wrote: > I doubt there's something like that. You can freeze arbitrary blocks of code > like this (from the manual) > > #<<<  format skipping: do not let perltidy change my nice formatting >    

Re: run pgindent on a regular basis / scripted manner

On 2023-Feb-05, Andrew Dunstan wrote: > So here's a diff made from running perltidy v20221112 with the additional > setting --valign-exclusion-list=", = => || && if unless" I ran this experimentally with perltidy 20230309, and compared that with the --novalign behavior (not to propose the latter

Re: run pgindent on a regular basis / scripted manner

Andrew Dunstan writes: > On 2023-04-26 We 09:27, Tom Lane wrote: >> Yeah, I agree, there is no case where that doesn't suck. I don't >> mind it imposing specific placements of brackets and so on --- >> that's very analogous to what pgindent will do. But it likes to >> re-flow comma-separated

Re: run pgindent on a regular basis / scripted manner

On 2023-04-26 We 09:27, Tom Lane wrote: 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

  1   2   3   4   >