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

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Tue, 18 Apr 2023 19:13:02 UTC

Severity: wishlist

Found in version 29.0.60

Full log


Message #88 received at 62940 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 62940 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing
 changes
Date: Tue, 15 Oct 2024 14:10:43 -0400
Dmitry Gutov <dmitry <at> gutov.dev> writes:
> On 11/10/2024 18:10, Spencer Baugh wrote:
>
>>     Or alternatively if we would prefer to err on the side of warning the
>>     user that the upstream has diverged, I suppose it's the Hg
>>     implementation that would need to change. That can result a simpler
>>     mental model and documentation as well. What would be Hg's
>>     corresponding
>>     selector for "tip of upstream branch"?
>> I'm not sure, I don't think there's no way to specify that with an
>> hg revset.  Though like most hg users, I don't actually use
>> branches, I use bookmarks; there's a way to do it with bookmarks, I
>> think. I'll investigate.
>
> Thanks. Or if it doesn't make sense for Hg (for example, if the remote
> tip will always be present locally too), that would also be good, then
> the current implementation is just right.

OK, so I don't see a good way to get "tip of upstream branch" with a
revset in hg.  You need to explicitly call "hg incoming" or similar, and
that returns a commit hash.  But even so, that doesn't really work with
hg branches, because the incoming commit hash won't actually be present
in the repository... I think.

But, all this is irrelevant.  Because, we don't actually care about the
upstream tip on its own: what we actually want is the mergebase of the
upstream tip and the working revision.

We can get that by calling the existing 'mergebase vc method.  To do
that, we need some way to specify the upstream tip revision when passing
it to 'mergebase as REV1.  (Omitting REV2 seems to just mean "use HEAD
as REV2", which is what we want.)  So I see two options:

A. Pass the symbol 'upstream, and have the 'mergebase backends handle it
   specially.

B. Add a new 'upstream-tip method; for vc-git this would return
   "@{upstream}" and for vc-hg it would return some special sentinel
   which vc-hg-mergebase handles.

Thoughts?  I'm happy with either of these solutions.




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.