GNU bug report logs - #62940
29.0.60; vc: no easy way to get diff of all outgoing changes

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Spencer Baugh <sbaugh <at> janestreet.com>, 62940 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes
Date: Thu, 15 May 2025 01:21:06 +0300

Hi Sean,

Thanks for joining the discussion.

On 11/05/2025 12:32, Sean Whitton wrote:
> Hello,
> 
> On Fri 11 Oct 2024 at 11:10am -04, Spencer Baugh wrote:
> 
>> I think it's useful to think of these two options relative to
>> vc-outgoing and vc-incoming.  Comparing $1 against $2 is equivalent to
>> getting the diff from $3:
>>
>> - working-tree merge-base = vc-outgoing
>> - merge-base remote-tip = vc-incoming
>> - working-tree remote-tip = vc-outgoing+vc-incoming
>>
>> The first two are more useful than the third, I think, since the third
>> mixes together two sorts of diffs, making it ambiguous which is which.
> 
> I agree that the first two are what is most useful.  The main use case
> for seeing a diff of all outgoing changes is to see a summary of all
> your outgoing work, and other people's incoming work isn't usually
> relevant to that.  When it is relevant, it is so only after pulling and
> rebasing or merging.

I indeed see less need for the third one, but it might be more useful in 
some (?) scenarios and environments where commits are a heavier 
operation, and/or one would want to evaluate the full changeset 
(compared to the branch's beginning) before making the next commit.

Not sure how often that occurs, though.

> If that's right, then the notions of "incoming" and "outgoing" are
> already well defined by vc-log-outgoing and vc-log-incoming and then I
> don't think I follow the motivation for wanting to use the forward
> completion mechanism with multiple possible forward completions.

It doesn't have to be forward history, but using revision completion 
seems like a distinct approach for this problem. And/or being able to 
choose revision through the universal prefix.

That can be valuable in that it would augment any command that calls 
vc-diff-build-argument-list-internal - including vc-diff-mergebase, 
vc-version-diff, vc-log-mergebase, vc-version-ediff.

Again, I don't have specific scenarios in mind, maybe others will 
comment with their emphasis.

> I have a couple of proposals for what to add and change to resolve this
> bug:
> 
> (1) Add a new vc-log-fileset-outgoing bound to C-x v o.  To get a diff
>      of all outgoing changes, you would use either 'C-x v o C-x h =' or
>      'C-x v O C-x h ='.
> 
> (2) Add these:
>      C-x v o L -- vc-log-fileset-outgoing
>      C-x v o D -- vc-diff-fileset-outgoing (equiv to 'C-x v o C-x h =' above)
> 
>      And a new defcustom which replaces the default C-x v O with these:
>      C-x v O L -- vc-log-outgoing
>      C-x v O D -- vc-diff-outgoing (equiv to 'C-x v O C-x h =' above)

This sounds interesting/useful to me, but we should probably realize 
that it amounts to declaring two new submaps - one for incoming and one 
for outgoing. Which we would later add new commands to over the years.

> I think I prefer option (2).  Would be great to hear from others, or if
> I've missed something additional that's wanted.

To clarify, how do you see the implementation of vc-diff-outgoing? Would 
it call the backend action 'log-outgoing' in a background buffer, then 
parse the output, call 'previous-revision' with the oldest revision in 
the list, and then invoke the diff? That sounds workable but also 
somewhat counter to vc's usual approach.

Thinking more about it, the actions 'log-incoming' and 'log-outgoing' 
themselves seem more specialized than what we usually want vc backend 
actions to be.

They could be re-implemented in terms of 'merge-base' and the currently 
proposed 'upstream-revision':

  (vc-log-mergebase nil upstream-revision working-revision)

and

  (vc-log-mergebase nil working-revision upstream-revision)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.