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: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>
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: Sun, 18 May 2025 12:04:30 +0100

Hello,

On Fri 16 May 2025 at 02:36am +03, Dmitry Gutov wrote:

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

Ah, right.

> IIUC vc-diff-fileset-outgoing wouldn't include those changes,

Right.

> or if it would, someone would prefer (or like to be able to) making
> the diff which doesn't include uncommitted changes.

You mean one that *does* include uncommitted changes, right?

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

Yeah.  Any thoughts on making it more discoverable?

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

Yes.  I'll work on that.

-- 
Sean Whitton

Previous Next

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