From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: run pgindent on a regular basis / scripted manner |
Date: | 2020-08-17 19:25:52 |
Message-ID: | 1084005.1597692352@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-08-15 13:44:34 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> One thing is that some here are actively against manually adding entries
>>> to typedefs.list.
>> I've been of the opinion that it's pointless to do so under the current
>> regime where (a) only a few people do that and (b) we only officially
>> re-indent once a year anyway. When I want to manually run pgindent,
>> I always pull down a fresh typedefs.list from the buildfarm, which is
>> reasonably up-to-date regardless of what people added or didn't add,
>> and then add any new typedefs from my current patch to that out-of-tree
>> copy.
> Well, properly indenting new code still is worthwhile. And once you go
> through the trouble of adding the typedefs locally, I don't really see
> the reason not to also include them in the commit.
Yeah, I'm quite religious about making sure my commits have been through
pgindent already (mainly to reduce subsequent "git blame" noise).
However, relying on manual updates to the in-tree typedefs.list only
works if every committer is equally religious about it. They're not;
else we'd not be having this discussion. The workflow I describe above
is not dependent on how careful everybody else is, which is why I
prefer it.
I think that the main new idea that's come out of this thread so far
is that very frequent reindents would be as good, maybe better, as
once-a-year reindents in terms of the amount of rebasing pain they
cause for not-yet-committed patches. If we can fix it so that any
mis-indented commit is quickly corrected, then rebasing would only be
needed in places that were changed anyway. So it seems like that
would be OK as a new project policy if we can make it happen.
However, I don't see any way to make it happen like that without
more-or-less automated reindents and typedefs.list updates,
and that remains a bit scary.
I did just have an idea that seems to ameliorate the scariness
a good bit: allow the reindent bot to auto-commit its results
only if the only lines it's changing are ones that were touched
by commits since the last auto-reindent. Otherwise punt and ask
a human to review the results. Not sure how hard that is to
implement, though.
Another good safety check would be to not proceed unless the latest
typedefs list available from the buildfarm is newer than the last
commit --- then we won't mess up recent commits whose typedefs are
not in the list yet.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-08-17 20:09:40 | Re: Improving connection scalability: GetSnapshotData() |
Previous Message | Alvaro Herrera | 2020-08-17 19:07:58 | Re: [BUG] Error in BRIN summarization |