Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qskz5-009EPq-RN for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Oct 2023 14:23:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qskz3-00AQ9X-PR for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Oct 2023 14:23:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qskz3-00AQ9P-Fr for pgsql-hackers@lists.postgresql.org; Tue, 17 Oct 2023 14:23:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qskyz-001Bt7-Rk for pgsql-hackers@postgresql.org; Tue, 17 Oct 2023 14:23:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39HENMFC2718059; Tue, 17 Oct 2023 10:23:22 -0400 From: Tom Lane To: Robert Haas cc: Peter Geoghegan , Andres Freund , Andrew Dunstan , Jelte Fennema , Michael Paquier , "shiy.fnst@fujitsu.com" , Justin Pryzby , Noah Misch , Bruce Momjian , Magnus Hagander , Alvaro Herrera , Stephen Frost , Jesse Zhang , "pgsql-hackers@postgresql.org" , Peter Eisentraut Subject: Re: run pgindent on a regular basis / scripted manner In-reply-to: References: <30a72ba4-9ca4-15b5-db0f-0e68cba7ab26@dunslane.net> <1f594a4b-14c8-e159-b250-edf8a091320d@dunslane.net> <20230811212511.aih23qfthi24zhq4@awork3.anarazel.de> <338202.1691793002@sss.pgh.pa.us> <342032.1691794926@sss.pgh.pa.us> <8c4d8afb-cda1-299c-8011-f60cdaff3999@dunslane.net> <20230812211404.sydbwo2juu7vyhtg@awork3.anarazel.de> <530189.1691880417@sss.pgh.pa.us> <544112.1691886017@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 17 Oct 2023 10:03:54 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2718057.1697552602.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Tue, 17 Oct 2023 10:23:22 -0400 Message-ID: <2718058.1697552602@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 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 thing to do, for instance. It's hard to say what frequency would lead to the least rebasing pain, but we know once-a-year isn't ideal. > For example, maybe we could have a bot. If you push a > commit that's not indented properly, the bot reindents the tree, > updates git-blame-ignore-revs, and sends you an email admonishing you > for your error. I'm absolutely not in favor of completely-automated reindents. pgindent is a pretty stupid tool and it will sometimes do stupid things, which you have to correct for by tweaking the input formatting. The combination of the tool and human supervision generally produces pretty good results, but the tool alone not so much. > 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 much against a commit hook. I think that'd be significantly more annoying than the current situation, which you're already unhappy about the annoying-ness of. The bottom line here, I think, is that there's a subset of committers that would like perfectly mechanically-indented code at all times, and there's another subset that just doesn't care that much. We don't (and shouldn't IMO) have a mechanism to let one set force their views on the other set. The current approach is clearly insufficient for that, and I don't think trying to institute stronger enforcement is going to make anybody happy. regards, tom lane