From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#70526: 29.2; package-vc-upgrade failed with error message "File is not under version control" Date: Wed, 24 Apr 2024 06:19:19 +0000 Message-ID: <87bk5zl1ug.fsf@posteo.net> References: <87pluflvmq.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13153"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70526 <70526@debbugs.gnu.org> To: "Yi Yue" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 24 08:21:37 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 1rzW0f-0003G3-5i for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Apr 2024 08:21:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzW0M-0007cV-0R; Wed, 24 Apr 2024 02:21:18 -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 1rzW00-0007Zx-O4 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 02:20:58 -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 1rzVzz-0003WW-6J for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 02:20:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rzW0F-0007Bw-9d for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 02:21:11 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Apr 2024 06:21:10 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70526 X-GNU-PR-Package: emacs Original-Received: via spool by 70526-submit@debbugs.gnu.org id=B70526.171393963927390 (code B ref 70526); Wed, 24 Apr 2024 06:21:10 +0000 Original-Received: (at 70526) by debbugs.gnu.org; 24 Apr 2024 06:20:39 +0000 Original-Received: from localhost ([127.0.0.1]:56705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzVzY-00075x-6a for submit@debbugs.gnu.org; Wed, 24 Apr 2024 02:20:36 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:40727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzVyq-0006zR-9n for 70526@debbugs.gnu.org; Wed, 24 Apr 2024 02:19:51 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D47FA240103 for <70526@debbugs.gnu.org>; Wed, 24 Apr 2024 08:19:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1713939560; bh=NU6xWYLzVungnBL9lbxb/yO2pYLGZRDevjmtzQjsxrs=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=kVaXBUTxbQg5hexAAiIDFj+WqBnsZYGR3KKukLhsNxyROLjneazP+iT6TxQxz3QZR TEPeKWlKulYB3J6lfuuNNk3ZBmhYBKWFmdJNdsG5mDxADd2s4jbF8YIHRRFOeMeWO1 Iy9P8bOTm+DM4eB51vNuC7jcthq34Bwr1crDtoJtJzZBkLwQ2vTWOH2CwwfqXiNHBR hezuQd0N36c6J0mn8Fj/n9rCIy0nAgDK+H2HpoHyIYZ35Tq91/9dxUSsYIK5f2ZPd3 9vC+KuA3HbWuE709hSIYZpi6vt6Ij/1vqFuzm9MneEWA+QvMoalEnBDMSf3EJClyFm RW8i2udro7K2Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VPTN81nnWz9rxB; Wed, 24 Apr 2024 08:19:20 +0200 (CEST) In-Reply-To: (Yi Yue's message of "Wed, 24 Apr 2024 11:00:32 +0900") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt 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:283905 Archived-At: --=-=-= Content-Type: text/plain "Yi Yue" writes: >> (unrelated, but why do your messages include HTML entities?) > > (Sorry, I forgot to forbid the default formatter of my email client.) it appears more or less correctly when I view the HTML message, so don't worry. >> My main fear is that this might have some unintended consequences. > > Of course. > >> I wouldn't want to rely on my understanding of vc either. While it >> would be easy to add a dynamic variable to indicate this behaviour, I am >> careful not to overburden the abstractions that VC provides. > > Understand. > > I read the docstring of `vc-pull', which is used by `package-vc-upgrade'. > It says: > > -------------------------------------------------------------------------- > "Update the current fileset or branch. > You must be visiting a version controlled file, or in a `vc-dir' buffer. > ..." > -------------------------------------------------------------------------- > > But `vc-dir' is a user command other than a function, it will open a new buffer and return nil. > In consideration of the fact that `vc-pull' is an async function, it is not easy for us to > kill the `vc-diff' buffer right after the pull operation. This actually gives us another possibility how to tackle the issue: --=-=-= Content-Type: text/plain Content-Disposition: inline diff --git a/lisp/emacs-lisp/package-vc.el b/lisp/emacs-lisp/package-vc.el index ef056c7909b..c29e8b5d738 100644 --- a/lisp/emacs-lisp/package-vc.el +++ b/lisp/emacs-lisp/package-vc.el @@ -774,6 +774,9 @@ package-vc-upgrade-all (package-vc-upgrade pkg-desc)))) (message "Done upgrading packages.")) +(declare-function vc-dir-prepare-status-buffer "vc-dir" + (bname dir backend &optional create-new)) + ;;;###autoload (defun package-vc-upgrade (pkg-desc) "Upgrade the package described by PKG-DESC from package's VC repository. @@ -810,7 +813,10 @@ package-vc-upgrade (remove-hook 'vc-post-command-functions post-upgrade)))))) (add-hook 'vc-post-command-functions post-upgrade) (with-demoted-errors "Failed to fetch: %S" - (let ((default-directory pkg-dir)) + (require 'vc-dir) + (with-current-buffer (vc-dir-prepare-status-buffer + (format " *vc-dir: %s*" pkg-dir) + pkg-dir (vc-responsible-backend pkg-dir)) (vc-pull))))) (defun package-vc--archives-initialize () --=-=-= Content-Type: text/plain I am actually satisfied with this approach, and it seems reliable. > > As you suggested earlier, maybe we need to modify vc.el, making the restriction looser? If you can, try out the above patch and tell me if you end up having any issues, otherwise I don't think we need to adjust vc. > Also, I noticed that the maintainer bind `default-directory' in this commit: > > https://github.com/emacs-mirror/emacs/commit/7ab556b57631cb28db86b89ba296bc0599d9a399 > Improve robustness of 'package-vc-update' Regards FYI that was my change, GitHub just doesn't display commit names by default: https://github.com/emacs-mirror/emacs/commit/7ab556b57631cb28db86b89ba296bc0599d9a399.patch -- Philip Kaludercic on peregrine --=-=-=--