From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: References: <640746f7-fa1c-dfb9-aaab-f9d8effdf64f@gutov.dev> <59c272ef-9909-4e0a-b3d7-b42fc14e54cc@gutov.dev> <1b04c2b0-e34e-4409-a133-0a711307e4ba@gutov.dev> Reply-To: Spencer Baugh Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15313"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62940@debbugs.gnu.org, Filipp Gunbin To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 16 22:13:08 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t1AOH-0003hI-Qp for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Oct 2024 22:13:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t1AMz-0005Xy-6L; Wed, 16 Oct 2024 16:11:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t1AMw-0005Uh-QA for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2024 16:11:42 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t1AMw-0000lr-H1 for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2024 16:11:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=54wBNyXLUBUlXdc5tfKrg4vTyQ7DxQ2JtRBVAuPdaf8=; b=V1hxCGgq74YePo3GCxkEgPSQmN0mNRf2d9Ki/fg0FqnVq/2BVic8fntxyd83GLCkfdMYdgNbFaUe3AxIO3ywVW9OwfRhirEbZXZmTBi6L74J/XI9C4IbI7lpxzQhquO2fT2mtUFJuHDVYpxDiw5ZkM0Y2zdB2OnmChLfC4HbFXhrudlk+5FXGvw9yMxvexb4smGQnAJtCMco5BBSpQvmpaUsKM3q2PyUJKTQU9iCLCXK5kR6Hnb4LLYuZOLWOdnZZpJdLQS3mO3ocjULgRpcp6BtUE2WIYy6VXMCnrsgQx0vmHxktV39oCD6LudnlruDCPivgKCFOkdL0rTqE+fXUg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t1ANG-0002rk-7r for bug-gnu-emacs@gnu.org; Wed, 16 Oct 2024 16:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Oct 2024 20:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62940 X-GNU-PR-Package: emacs Original-Received: via spool by 62940-submit@debbugs.gnu.org id=B62940.172910951010997 (code B ref 62940); Wed, 16 Oct 2024 20:12:02 +0000 Original-Received: (at 62940) by debbugs.gnu.org; 16 Oct 2024 20:11:50 +0000 Original-Received: from localhost ([127.0.0.1]:60587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1AN4-0002rJ-43 for submit@debbugs.gnu.org; Wed, 16 Oct 2024 16:11:50 -0400 Original-Received: from mxout1.mail.janestreet.com ([38.105.200.78]:44001) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t1AN1-0002r2-UQ for 62940@debbugs.gnu.org; Wed, 16 Oct 2024 16:11:48 -0400 In-Reply-To: <1b04c2b0-e34e-4409-a133-0a711307e4ba@gutov.dev> (Dmitry Gutov's message of "Wed, 16 Oct 2024 23:02:12 +0300") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1729109482; bh=54wBNyXLUBUlXdc5tfKrg4vTyQ7DxQ2JtRBVAuPdaf8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=nX7vJVOCsemdmhKviW3KZU9lVoe97tF25CYSCiPXqO0V9KhdRss1Zz35wCvix4jK7 1SpTTBnSt0AUchd07vwzlOq3Gd6TUhshK3DZ5lh5TEdnre/5aZP6TiB7h3BedsWJvi Hbs+aMkOdH3oeqgCGQlZjty+TdKvefCaDXUxjFWaXjXnhcl4cbrwy+XsOO/M8U0SCF S5KFTrxGI15QYg8MN8THJ3CZDT6zTQLvtUcPOUjGjCL+jLMdRcbT/Hz2xUtAD4s3Cs ps8/XwlXS3rSaAjaOAVaCJkFcbUwlZgUDxOjHOFxisTztU0neAiIx2wmjOQuuhLOPt p/H2CO4B8mIJg== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:293689 Archived-At: Dmitry Gutov writes: > On 15/10/2024 21:10, Spencer Baugh wrote: >> Dmitry Gutov 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 simpl= er >>>> 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.=C2=A0 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?