Subject: bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes

From: Sean Whitton <[email-masked]>
Date: Thu, 15 May 2025 13:57:35 +0100

Hello,

On Thu 15 May 2025 at 01:21am +03, Dmitry Gutov wrote:

> 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.

Right.  I think I'd like to see a case where just doing a 'vc-pull'
first is not okay.

>> 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.

Right, okay.  The flexibility is certainly attractive.  I guess I see
the existing -incoming- and -outgoing- commands and there is an obvious
(to me) gap for adding a few additional commands as a simpler solution.

Where stage do you think your thoughts on these virtual revisions are
at?  I think I could pretty much go ahead and implement my solution to
this bug now; that is not a reason in itself to go and do it, if you
still want to consider your idea further.

>> 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.

We might, yeah, though 'C-x v M' has remained fairly pure.

>> 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.

I was thinking that the backend would query the remote to find out what
revision to fetch, fetch it, and then diff directly.  I.e. there
wouldn't be a need to go via log-outgoing.  Perhaps I am missing
something that makes you think it'd have to go via log-outgoing?

> 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)

Yes, that would be a sensible refactoring.

-- 
Sean Whitton