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: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 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: Wed, 16 Oct 2024 23:02:12 +0300

On 15/10/2024 21:10, Spencer Baugh wrote:
> 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.

I guess the main problem with 'hg incoming' is that it does I/O, and 
might take a while - unlike Git's separate step of 'git fetch' which 
saved "remote" references to be used by other commands.

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

I think if there is no feasible way to do the same with Hg, we might as 
well install a halfway solution for it, which (in your latest proposal) 
returns the mergebase already. With a FIXME comment, maybe.

As a result, the core feature will work (the "outgoing" diff), whereas 
the "incoming" diff would only be accessible for Git repositories. Also, 
with Git, one might need to use vc-log-mergebase when the remote has 
diverged.

Previous Next

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