From: Dmitry Gutov <dmitry@gutov.dev>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 62940@debbugs.gnu.org, Filipp Gunbin <fgunbin@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 [thread overview]
Message-ID: <1b04c2b0-e34e-4409-a133-0a711307e4ba@gutov.dev> (raw)
In-Reply-To: <iercyk1kzj0.fsf@janestreet.com>
On 15/10/2024 21:10, Spencer Baugh wrote:
> Dmitry Gutov <dmitry@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.
next prev parent reply other threads:[~2024-10-16 20:02 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 19:12 bug#62940: 29.0.60; vc: no easy way to get diff of all outgoing changes Spencer Baugh
2023-04-18 20:36 ` Filipp Gunbin
2023-04-18 20:43 ` Dmitry Gutov
2023-04-19 6:49 ` Juri Linkov
2023-08-14 19:42 ` Spencer Baugh
2023-08-16 7:48 ` Juri Linkov
2024-09-13 20:54 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-14 2:11 ` Dmitry Gutov
2024-09-14 7:12 ` Eli Zaretskii
2024-10-10 0:26 ` Dmitry Gutov
2024-10-10 5:27 ` Eli Zaretskii
2024-10-11 1:13 ` Dmitry Gutov
2024-10-11 6:07 ` Eli Zaretskii
2024-10-11 14:40 ` Dmitry Gutov
2024-10-11 1:34 ` Dmitry Gutov
2024-10-11 14:39 ` Dmitry Gutov
2024-10-11 15:10 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-11 20:28 ` Dmitry Gutov
2024-10-11 22:38 ` Dmitry Gutov
2024-10-12 8:32 ` Eli Zaretskii
2024-10-15 18:10 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-16 20:02 ` Dmitry Gutov [this message]
2024-10-16 20:11 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-10-16 23:53 ` Dmitry Gutov
2023-04-18 21:59 ` Spencer Baugh
2023-04-21 18:36 ` sbaugh
2023-04-22 6:57 ` Eli Zaretskii
2023-04-22 13:00 ` sbaugh
2023-04-22 13:17 ` Eli Zaretskii
2023-04-22 18:33 ` Dmitry Gutov
2023-04-22 19:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b04c2b0-e34e-4409-a133-0a711307e4ba@gutov.dev \
--to=dmitry@gutov.dev \
--cc=62940@debbugs.gnu.org \
--cc=fgunbin@fastmail.fm \
--cc=sbaugh@janestreet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.