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

Previous Next

Full log

Message #94 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: Wed, 16 Oct 2024 16:11:21 -0400

Dmitry Gutov <dmitry <at> gutov.dev> writes:

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

Right.  But note that the Hg revset in my original patch finds what is
effectively the mergebase with upstream, without doing any network IO.
Hg is able to find that mergebase without IO, but actually finding the
upstream tip requires network IO as you said.

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

Right, that makes sense to me.

Just to be clear, you're suggesting the incoming diff would be
accessible for a Git repository via vc-diff-mergebase, right?

Previous Next

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