From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 00149f18ea9: Support modifying VC change comments for Git Date: Wed, 23 Oct 2024 22:40:46 +0300 Message-ID: <0c8be7e4-7fb7-4b90-9d27-8d18546d7a01@yandex.ru> References: <86r087dvqa.fsf@gnu.org> <87ttd39mm1.fsf@melete.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5419"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Sean Whitton , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 23 21:42:07 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t3hF8-0001IJ-Nw for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Oct 2024 21:42:06 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t3hED-0007Qr-FO; Wed, 23 Oct 2024 15:41:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t3hEA-0007Qc-Ij for emacs-devel@gnu.org; Wed, 23 Oct 2024 15:41:06 -0400 Original-Received: from forward502d.mail.yandex.net ([178.154.239.210]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t3hE5-0001ka-Qs; Wed, 23 Oct 2024 15:41:06 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:5e21:0:640:3ef2:0]) by forward502d.mail.yandex.net (Yandex) with ESMTPS id BDA0C615CB; Wed, 23 Oct 2024 22:40:51 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id neZ3VX9X1eA0-Asf92wy7; Wed, 23 Oct 2024 22:40:51 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1729712451; bh=fGzEL5Eu8LkXV1kY2G3Nxxfz2RADIk3a5kmrjGTBlBg=; h=In-Reply-To:From:Subject:Message-ID:Cc:References:Date:To; b=CP/O0FBvLD8vvOjqlMlFHZi+2iS90fT1b07g0i3SdTo5Igbo3wcYDjgnd4hE5ub6q jWh20rzQROn0DO4llmEp+1E0V1gTlK1+SMytXiW2fSh6TEj4FhJ8cQLurGXqZU0jRw oRIwnVikdcrWDkyLEndK/leV/vLdthr0Qn3szb7E= Authentication-Results: mail-nwsmtp-smtp-production-main-69.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id E75AD1200043; Wed, 23 Oct 2024 15:40:48 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Wed, 23 Oct 2024 15:40:48 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdeijedgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddv jeenucfhrhhomhepffhmihhtrhihucfiuhhtohhvuceoughguhhtohhvseihrghnuggvgi drrhhuqeenucggtffrrghtthgvrhhnpeeihfejueevteffffdvfeetffffkefhuedujeei heehiedulefghefgffefudffudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegughhuthhovhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqudeffeefleelheehvddqvdelgeejjeejjeeiqdgughhuthhovheppeihrghnug gvgidrrhhusehfrghsthhmrghilhdrtghomhdpnhgspghrtghpthhtohepfedpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepshhpfihhihhtthhonhesshhpfihhihhtthhonh drnhgrmhgvpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepvghm rggtshdquggvvhgvlh X-ME-Proxy: Feedback-ID: ib1d9465d:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Oct 2024 15:40:47 -0400 (EDT) Content-Language: en-US In-Reply-To: <87ttd39mm1.fsf@melete.silentflame.com> Received-SPF: pass client-ip=178.154.239.210; envelope-from=dgutov@yandex.ru; helo=forward502d.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324803 Archived-At: Hi! On 23/10/2024 12:47, Sean Whitton wrote: > On Wed 23 Oct 2024 at 12:17pm +03, Eli Zaretskii wrote: > >> The values of the new option vc-allow-rewriting-published-history >> could have their mnemonic value improved (and also become more >> consistent with our practices elsewhere), if they were changed as >> follows: >> >> nil (default): don't allow >> ask: ask whether to allow >> t: allow without asking >> >> The current values, where t means "ask for confirmation" and 'no-ask' >> allows without asking is IMO sub-optimal, because t usually means in >> Emacs "do something unconditionally". >> >> So I suggest to change the values as described above. > `ask' is nicer than `no-ask', indeed. I am however keen to steer people > towards `ask'. In addition to t often meaning "do something > conditionally", it often means "turn this on in the most common way" > even if the most common way is not the most permissive way. > > I would be grateful for more opinions on how this option should look. > CCing Dmitry. I think I prefer Eli's suggestion, simply because it is more straightforward and has precedent. The more exotic schemes we have somewhere are probably due to history, where a new possibility had been added to an existing option, and the decision was to retain the current behavior by default. If we want to steer towards "ask", changing the default would probably be the most efficient approach.