Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRyRw-000313-L1 for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Feb 2023 16:46:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pRyRu-000303-VL for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Feb 2023 16:46:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRyRu-0002zs-LU for pgsql-hackers@lists.postgresql.org; Tue, 14 Feb 2023 16:46:34 +0000 Received: from relay10.mail.gandi.net ([2001:4b98:dc4:8::230]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pRyRs-0001C9-4T for pgsql-hackers@postgresql.org; Tue, 14 Feb 2023 16:46:34 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id B042824000B; Tue, 14 Feb 2023 16:46:25 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------MPX0g68W6COXXVVKNoxJwjS3" Message-ID: Date: Tue, 14 Feb 2023 11:46:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: run pgindent on a regular basis / scripted manner Content-Language: en-US To: Jelte Fennema Cc: "shiy.fnst@fujitsu.com" , Robert Haas , Tom Lane , Justin Pryzby , Andres Freund , Noah Misch , Peter Geoghegan , Bruce Momjian , Magnus Hagander , Alvaro Herrera , Stephen Frost , Jesse Zhang , "pgsql-hackers@postgresql.org" References: <3d67bc80-4de2-5ba8-e272-e4ad2e59ba04@dunslane.net> <4ac8f263-f1bb-faa5-a307-1fffe00f0e3e@dunslane.net> <0f074818-b01a-799f-3c74-5fb5deab1d23@dunslane.net> <1d66447e-a77b-ca0d-90a0-782800e85383@dunslane.net> <390e7b04-11f3-f715-7a7d-d1a9077fbea8@dunslane.net> <00885533-ff96-2a95-7911-329c873b3029@dunslane.net> <6fe4153d-8363-7d57-d651-ee6b75b2f296@dunslane.net> From: Andrew Dunstan In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------MPX0g68W6COXXVVKNoxJwjS3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. I don't want to implement an option that three people are going to use. > > In the general case I agree with you. But in this specific case I > don't. To me the whole point of this email thread is to nudge people > towards indenting the changes that they are committing. Thus indenting > those changes (either before or after adding) is the workflow that we > want to make as easy as possible. Because even if it's not people > their current workflow, by adding the flag it hopefully becomes their > workflow, because it's so easy to use. So my point is we want to > remove as few hurdles as possible for people to indent their changes > (and setting up git aliases or pre-commit hooks are all hurdles). (ITYM "remove as many hurdles as possible"). It remains to be seen how much easier any of this will make life for committers, at least. But I concede this might make life a bit simpler for developers generally. Anyway, let's talk about the details of what is proposed. So far, we have had the following categories suggested: dirty, staged, dirty+staged, untracked. Are there any others? Another issue is whether or not to restrict these to files under the current directory. I think we probably should, or at least provide a --relative option. cheers andrew -- Andrew Dunstan EDB:https://www.enterprisedb.com --------------MPX0g68W6COXXVVKNoxJwjS3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit


On 2023-02-13 Mo 13:29, Jelte Fennema wrote:
On Mon, 13 Feb 2023 at 17:47, Andrew Dunstan <andrew@dunslane.net> 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 three people are going to use.


In the general case I agree with you. But in this specific case I
don't. To me the whole point of this email thread is to nudge people
towards indenting the changes that they are committing. Thus indenting
those changes (either before or after adding) is the workflow that we
want to make as easy as possible. Because even if it's not people
their current workflow, by adding the flag it hopefully becomes their
workflow, because it's so easy to use. So my point is we want to
remove as few hurdles as possible for people to indent their changes
(and setting up git aliases or pre-commit hooks are all hurdles).


(ITYM "remove as many hurdles as possible"). It remains to be seen how much easier any of this will make life for committers, at least. But I concede this might make life a bit simpler for developers generally.

Anyway, let's talk about the details of what is proposed.

So far, we have had the following categories suggested: dirty, staged, dirty+staged, untracked. Are there any others?

Another issue is whether or not to restrict these to files under the current directory. I think we probably should, or at least provide a --relative option.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com
--------------MPX0g68W6COXXVVKNoxJwjS3--