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>
Cc: 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: Fri, 16 May 2025 02:36:33 +0300

On 15/05/2025 15:57, Sean Whitton wrote:
> 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.

Sorry, I was commenting on one thing, but had in mind something 
different. Probably the fault of my earlier message which didn't make a 
distinction between the working tree and the working revision.

What I was referring to, is the item D. from the original report's 
description: being able to make the diff between the last pushed 
revision ("upstream revision" or merge-base with it) and the current 
state of the working directory, including the uncommitted changes.

IIUC vc-diff-fileset-outgoing wouldn't include those changes, or if it 
would, someone would prefer (or like to be able to) making the diff 
which doesn't include uncommitted changes.

IOW

  git diff origin/HEAD..HEAD

vs

  git diff origin/HEAD

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

Can't say for sure: a couple of patches I posted implement variants of 
this approach, but I'm not clear on whether the UI is good enough to 
others' usability. Or big enough an improvement over the current 
capability - where one could input the base revision once, and get it 
from history later.

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

Yeah, these approaches don't seem to conflict.

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

Fair point. I wonder how many are really aware of this submap, and of 
the 'C-x v b' submap as well.

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

Okay, and to do that we would also need to add a new backend action, 
like 'upstream-revision'?

If so, that would be a common ground between several proposals, and thus 
a good path forward.

Previous Next

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