From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes Date: Thu, 10 Oct 2024 08:27:30 +0300 Message-ID: <86msjc34u5.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18454"; mail-complaints-to="usenet@ciao.gmane.io" Cc: sbaugh@janestreet.com, 62940@debbugs.gnu.org, fgunbin@fastmail.fm To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 10 07:29:25 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 1syljp-0004gX-7r for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Oct 2024 07:29:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syljM-0001sC-H1; Thu, 10 Oct 2024 01:28:56 -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 1syljJ-0001rs-0W for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 01:28:53 -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 1syljI-0003zo-HC for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 01:28:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=8pxvprXZe0bKsVYfeExw7qdX9iJiGR72WyXNHWTGdcg=; b=l091CO8hTTpfzMorlGpMkKk+r+VEbnggv2RwgIyaTUri7RJfbteVL5WYXdZ725ibl+J2VkFAhfAB7mxUc5ZkhgjEJzDySE6Y4UzLziOk1XmNG9Ofxcty6I/3Ug0LT6pZJlwf4D+NOkzD2wOC2/6piMCRi14rojwQMzfrkyPV2FoVTcEQK2AagGxn3zD3gj4VhJ3ja/qpb6QsH78tguJw8LafyXj5weAHi97Kr9IX6WXmx36ac7k1d6Co04L0sWZpDC8oA1j3fwyFHkGID5BQ1drmdrrME7aT84q0xFrrsUY0QkvpZsV5a+SPrmUDltPASJwecmG/flH/TYJPD0XBkQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1syljS-0001q3-E1 for bug-gnu-emacs@gnu.org; Thu, 10 Oct 2024 01:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Oct 2024 05:29: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.17285380846993 (code B ref 62940); Thu, 10 Oct 2024 05:29:02 +0000 Original-Received: (at 62940) by debbugs.gnu.org; 10 Oct 2024 05:28:04 +0000 Original-Received: from localhost ([127.0.0.1]:58365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syliW-0001oi-32 for submit@debbugs.gnu.org; Thu, 10 Oct 2024 01:28:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syliR-0001oA-O3 for 62940@debbugs.gnu.org; Thu, 10 Oct 2024 01:28:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1syliA-0003lG-Ps; Thu, 10 Oct 2024 01:27:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8pxvprXZe0bKsVYfeExw7qdX9iJiGR72WyXNHWTGdcg=; b=pWMTz5nzlfW2 6WLELJmDvTr4UCPP8SPXUWtPyu1iYEprWmjOMyoZtpiZ1RY5beG1R3AzBQHtKqWntueWFMbhEYe2d +UD1XMlf/1RrusuHAcmqO8Pbf4MScZQOxpTO84cvUDopD7hH7iwf3Gr1lp0ZOx/6ViXBuYIbA/5Ab 8cTh4ixe+mWMPJk6dTffZ/UGZZo29GNSuT9vNAkXmPAqHjiHqoHDK0QQlJG0dn9zV9Y4CxGRoxFfo pMHHzKLgjCMW4FmxENFOon0HRuPNj+QgSNzjiZytYje4aV1MfiLml8dos5I0BbO15k1eAG7zwDh5Z 9Bp3P3d6H02K0QLqa1NuAA==; In-Reply-To: <030ceec6-427a-49af-a42e-2ad11f9a591b@gutov.dev> (message from Dmitry Gutov on Thu, 10 Oct 2024 03:26:23 +0300) 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:293244 Archived-At: > 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). 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. > 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.