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
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
This bug report was last modified 24 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.