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.bugs Subject: bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes Date: Fri, 11 Oct 2024 04:13:24 +0300 Message-ID: <30132e72-ad22-493a-b89e-cffcedeee705@gutov.dev> References: <640746f7-fa1c-dfb9-aaab-f9d8effdf64f@gutov.dev> <02b37700-a48d-4a7c-8e61-b37dfbabc062@gutov.dev> <86r09miu90.fsf@gnu.org> <030ceec6-427a-49af-a42e-2ad11f9a591b@gutov.dev> <86msjc34u5.fsf@gnu.org> 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="876"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: sbaugh@janestreet.com, 62940@debbugs.gnu.org, fgunbin@fastmail.fm To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 11 03:14:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sz4ER-000Adb-Sw for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Oct 2024 03:14:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sz4EA-0003YV-6j; Thu, 10 Oct 2024 21:13:59 -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 1sz4E2-0003Xq-SG for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 21:13:52 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sz4E2-0007bQ-KJ for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 21:13:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=12SsXtRnrbz+mMQb+TTKqUusQ/8ApnY3HHo1ck4tsys=; b=c5997YP0ndgO1ACfRCE2nUtDlv5DBTl4DNA9628ZlxQUndLBoUEQm39PFi00p8xxe9hJ4/6wlssL8YwOg3jIn3vhNtsWuEcLqsrTPwHYEuGWqxDu0yTSytLELjOwTrxRh6xD44obak0jJVQsmwuPk1+XK35QieZf0BqUMBD0wKzZm9Nx/0zGGb8rI4aHiln/O6B/gzK8Y3RdPf4uunxMGyTSdnOGvaJzgW6E1KxCxCq8Nc70Sj2B0mg4WhHGFFDeCbNr7R2QdFE2zUOdJyvK1s39+8yT5piaHwR/bCayJP23ZsrmGEmz4HHbYDqhJPGAd+3W46UosOuIcMwa8Qcnpw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sz4EE-0005FB-9M for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 21:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Oct 2024 01:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62940 X-GNU-PR-Package: emacs Original-Received: via spool by 62940-submit@debbugs.gnu.org id=B62940.172860923020127 (code B ref 62940); Fri, 11 Oct 2024 01:14:02 +0000 Original-Received: (at 62940) by debbugs.gnu.org; 11 Oct 2024 01:13:50 +0000 Original-Received: from localhost ([127.0.0.1]:60976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sz4E1-0005EX-7w for submit@debbugs.gnu.org; Thu, 10 Oct 2024 21:13:49 -0400 Original-Received: from fout-a8-smtp.messagingengine.com ([103.168.172.151]:53455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sz4Dx-0005EI-A6 for 62940@debbugs.gnu.org; Thu, 10 Oct 2024 21:13:48 -0400 Original-Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id A689D13801AE; Thu, 10 Oct 2024 21:13:27 -0400 (EDT) Original-Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Thu, 10 Oct 2024 21:13:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1728609207; x=1728695607; bh=12SsXtRnrbz+mMQb+TTKqUusQ/8ApnY3HHo1ck4tsys=; b= EXJ5wAWxUEHK+hxPngiMOzjFlBGJxZJw/rJuCZjxZSxzVP9vzMt9qv5qHssB6kSh 2kLx3agWrYcUiiBwjZ0/wubaxMjosmuO1EwSlvI6fcxkSM+CY2+MYb9gC9x7yUxe gKVHxo9QWLf5SpPTIkuSkRr5rEhsY6z0TOQtyHlLklrQyU3Tp+b7hJaEBXcqtGa7 HkQWrRh9RNWbm8hUfy4k4qR7eczkNVCoc96WX9EPJ+yOxK7neB6Fuzw2Jw3lNicO Bs/hkegKr2oKhPHECaHw3Gy2n+EimgnuE7MMJLAFZEi9RIX1mtc07+kG1SzX1R3U L642bpgcdMfYRaoTJTtZ6w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1728609207; x= 1728695607; bh=12SsXtRnrbz+mMQb+TTKqUusQ/8ApnY3HHo1ck4tsys=; b=L Q4NMbNmuw6r6b5GyVGO41RZ38Vqe2OZpOfrT60cHnH1WxDRj7rxqu5yN2kYEvX1G Rds1rBTpWd4QxgEaNiq7XGBaKPi6E2C1F01auE8ctS/hoeJI5hjNIpalzVZ1bcqI 6+eXl8SZu7TPqkoWgtikg5NuOHXbetiIazEHubqrDyeoBJ9bhcrix9VqKsobhGFK pUwE6Hj6+y8gjMGAa8/beUcU9x7n9MC0hG57GgT5U0EqO4JohRTX/Z2BSvKHtKAH qIAjk6TT6xgZJ8C1CsNd/GiKdpxY+NYxfb1NtBRNtqcT2en4+Kc8OCo1urEYs8mt +1rI6AalkfWi1hJ0G1+fQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdefjedggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdej necuhfhrohhmpeffmhhithhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdrug gvvheqnecuggftrfgrthhtvghrnhepteduleejgeehtefgheegjeekueehvdevieekueef tddvtdevfefhvdevgedujeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthho peegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh dprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthht ohepiedvleegtdesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehfghhunh gsihhnsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Oct 2024 21:13:26 -0400 (EDT) Content-Language: en-US In-Reply-To: <86msjc34u5.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:293324 Archived-At: On 10/10/2024 08:27, Eli Zaretskii wrote: >> Date: Thu, 10 Oct 2024 03:26:23 +0300 >> Cc: sbaugh@janestreet.com, 62940@debbugs.gnu.org, fgunbin@fastmail.fm >> From: Dmitry Gutov >> >> On 14/09/2024 10:12, Eli Zaretskii wrote: >>> More importantly, this change must be accompanied with a suitable >>> update of the user manual, where we should explain what commit is >>> suggested as the default. "Last pushed revision" is somewhat vague >>> and inaccurate, because the user could switch branches or remotes, or >>> do something else. We should find a more accurate description. Also, >>> the doc string of vc-root-diff needs to be updated with this >>> information. >> >> I wonder how you'd like to see these changes described. > > What I had in mind was to explain what we mean by "last pushed > revision". AFAICT, you use "the previous revision when the fileset > changed" instead. IMO, this terminology has the same problem: it > doesn't account for changing branches or remotes, for example. We > should somehow qualify the description by those situations (which I > agree are somewhat exceptional, but definitely not rare enough to be > ignored). Not sure what you mean by changing branches, given the revision default that is used is determined by the tip of the local branch. > Moreover, the patch to which I posted the comments uses > "last pushed revision" all over the place, so if we want to use your > proposed terminology instead, we had better modified the doc strings > to use it as well. It's another term, we'll actually need both (possibly rephrased). >> If we also add the story about the second default being the upstream >> revision, with a description of how such is determined, it might >> overload the text. Maybe for no good reason if most people don't use >> 'C-u' with 'C-x v =' anyway, even if for some it's handy. > > I don't see a reason why explaining that should take more than a > couple of sentences. > >> Should this be a whole separate node, "Reading Revisions for Diff With >> Completion"? > > I don't think that is needed. If we think some parts of the > description are "too much detail", we could have them in footnotes. Okay, check out this attempt. It might be considered too cluttered. Perhaps you will have suggestions for improvement. diff --git a/doc/emacs/maintaining.texi b/doc/emacs/maintaining.texi index 99219b7f5d7..d50219f0688 100644 --- a/doc/emacs/maintaining.texi +++ b/doc/emacs/maintaining.texi @@ -881,13 +881,16 @@ Old Revisions @kindex C-u C-x v = To compare two arbitrary revisions of the current VC fileset, call -@code{vc-diff} with a prefix argument: @kbd{C-u C-x v =}. This -prompts for two revision IDs (@pxref{VCS Concepts}), and displays a -diff between those versions of the fileset. This will not work -reliably for multi-file VC filesets, if the version control system is -file-based rather than changeset-based (e.g., CVS), since then -revision IDs for different files would not be related in any -meaningful way. +@code{vc-diff} with a prefix argument: @kbd{C-u C-x v =}. This prompts +for two revision IDs (@pxref{VCS Concepts}), and displays a diff between +those versions of the fileset. The first one has several default +values: the revision before the last one when the fileset changed, and +the last revision of the current branch's upstream. +The second defaults to nil, which means the contents of +the work tree. This will not work reliably for multi-file VC filesets, +if the version control system is file-based rather than changeset-based +(e.g., CVS), since then revision IDs for different files would not be +related in any meaningful way. Instead of the revision ID, some version control systems let you specify revisions in other formats. For instance, under Bazaar you @@ -921,6 +924,9 @@ Old Revisions prompts for two revision IDs (@pxref{VCS Concepts}), and displays a diff between those versions of the entire version-controlled directory trees (RCS, SCCS, CVS, and SRC do not support this feature). +The first one has several default values: the revision before the last +one when the fileset changed, and the last revision of the current +branch's upstream. @vindex vc-diff-switches You can customize the @command{diff} options that @kbd{C-x v =} and