unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dmitry@gutov.dev>
To: Eli Zaretskii <eliz@gnu.org>
Cc: sbaugh@janestreet.com, 62940@debbugs.gnu.org, fgunbin@fastmail.fm
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	[thread overview]
Message-ID: <30132e72-ad22-493a-b89e-cffcedeee705@gutov.dev> (raw)
In-Reply-To: <86msjc34u5.fsf@gnu.org>

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 <dmitry@gutov.dev>
>>
>> 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






  reply	other threads:[~2024-10-11  1:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 19:12 bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes Spencer Baugh
2023-04-18 20:36 ` Filipp Gunbin
2023-04-18 20:43   ` Dmitry Gutov
2023-04-19  6:49     ` Juri Linkov
2023-08-14 19:42       ` Spencer Baugh
2023-08-16  7:48         ` Juri Linkov
2024-09-13 20:54     ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-14  2:11       ` Dmitry Gutov
2024-09-14  7:12         ` Eli Zaretskii
2024-10-10  0:26           ` Dmitry Gutov
2024-10-10  5:27             ` Eli Zaretskii
2024-10-11  1:13               ` Dmitry Gutov [this message]
2024-10-11  6:07                 ` Eli Zaretskii
2024-10-11 14:40                   ` Dmitry Gutov
2024-10-11  1:34       ` Dmitry Gutov
2024-10-11 14:39         ` Dmitry Gutov
2024-10-11 15:10           ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-11 20:28             ` Dmitry Gutov
2024-10-11 22:38               ` Dmitry Gutov
2024-10-12  8:32                 ` Eli Zaretskii
2023-04-18 21:59   ` Spencer Baugh
2023-04-21 18:36     ` sbaugh
2023-04-22  6:57       ` Eli Zaretskii
2023-04-22 13:00         ` sbaugh
2023-04-22 13:17           ` Eli Zaretskii
2023-04-22 18:33             ` Dmitry Gutov
2023-04-22 19:27               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30132e72-ad22-493a-b89e-cffcedeee705@gutov.dev \
    --to=dmitry@gutov.dev \
    --cc=62940@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=fgunbin@fastmail.fm \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).