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.devel Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS Date: Sun, 30 Oct 2022 14:15:07 +0000 Message-ID: <87edupbdp0.fsf@posteo.net> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <83wn8z2aze.fsf@gnu.org> <878rle1i0k.fsf@posteo.net> <87ilkelc10.fsf@posteo.net> <878rl6syg8.fsf@posteo.net> <87zgdjqcu0.fsf@posteo.net> <87zgdivc3f.fsf@posteo.net> <874jvqv2u3.fsf@posteo.net> <875yg6qtbl.fsf@posteo.net> <87ilk33lqk.fsf@posteo.net> <87mt9epqlk.fsf@posteo.net> <87ilk1bgvd.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37017"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 30 15:16:00 2022 Return-path: Envelope-to: ged-emacs-devel@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 1op96W-0009Ou-Kn for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Oct 2022 15:16:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1op95r-0001Lb-To; Sun, 30 Oct 2022 10:15:19 -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 1op95q-0001LU-EQ for emacs-devel@gnu.org; Sun, 30 Oct 2022 10:15:18 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1op95o-0004Fp-Is for emacs-devel@gnu.org; Sun, 30 Oct 2022 10:15:18 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 421C4240103 for ; Sun, 30 Oct 2022 15:15:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667139314; bh=BNZRhoNtGwEvQxfmOFzKETqa23cHtLeTCTqQ/rTs8SE=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=fwBIMV+uNmHYn92mkPXVcFemyoC+YaMpylVhexfWFfaAlaHldUcagnfBLXThwlsh5 OsDb4x7FCUeJpo6sM32/9LW5CId1OFxHJnsuaXmUBVGWT3eLjR98jqNH4w/kgJ3pLk 72sb3TokVLloM1rBewrxYvYvMjYqG6hP5Ro8HXnfa4FeeLnPldLDS12iH564H8gULo 9yKjuYUXe/9jwA/OnGR4SINdgbLLV3p2XfD1O7/sf2Z49DBeO52B/66OqkhWbhs4lo Hj176VtU/jzk8R4HjU3Ey1kFkMpcVsBy7KjoJc4Alju1wRBDJ1/zO3de0RC9UD1+LD nRiP3W5gg9kRw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N0dbL2vjfz6tnX; Sun, 30 Oct 2022 15:15:07 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Sun, 30 Oct 2022 10:00:40 -0400") Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298816 Archived-At: Stefan Monnier writes: >> I guess so. Here is a possible patch that should behave close enough to >> elpa-admin.el using "blame" > > Why do you use `blame` rather than `log` like `elpa-admin.el`? I tried to use log like in elpa-admin.el, but the issue was I had to either 1. Define the generic interface to search for a line using a regular expression that is not an Elisp regular expression, and could conceivably differ between different VCS that might also implement 'last-change'. 2. Deal with the issue that the Version header might move between revisions, meaning that a line range wouldn't do a good job at capturing the right commit. >> (an obvious exception is the missing handler for the new :merge >> property, but I have been wondering if it might also be fair to always >> add "--first-parent" for Git). > > We considered using `--first-parent` but it tends to point to more > recent merge commits than to the actual commit that bumped the > `Version:`. If you add to that the fact that order of parents in Git is > somewhat arbitrary and rarely taken into consideration, I'd rather not > go there. > > For `:merge` we didn't really have a choice, and (to make up for that) > we get to control how the merge is done and thus which one is the > first parent. I see. >> The default handler just wraps vc-annotate, so it is a bit more fragile. > > Hmm... the code I see in your patch uses `vc-region-history` (which is > only supported for Git and Hg, currently, and is fairly difficult to > support in a generic way) rather than `vc-annotate`. > Am I missing something? Uh, that is my mistake. I started writing that code yesterday (I believe?) and simply forgot what I had used. I'll try to translate that into vc-annotate before pushing anything. >> Invoking `package-vc-install' with a prefix argument will now check out >> the specific commit that bumps the version tag. At least for git, the >> slight problem here is that this means the head is in a detached state, >> not connected to any specific branch. I don't know if there is any >> elegant solution to this problem, or if it should even be "solved". > > I suspect a better option is to use something like `git reset` instead > of `git checkout`, so we end up at the right revision but still on the > main branch. But yes, it's kind of ugly if you want to try and preserve > local changes. I think doing it right requires distinguishing whether > we're moving forward or backward (moving forward can be done with `git > merge`, which is well-behaved, whereas moving backward is poorly > supported, AFAICT). Checking out a specific revision is currently only done right after cloning, so this is always a reset. The issue here is that I am trying to stay generic and was using 'vc-retrieve-tag' (but perhaps 'vc-checkout' would be better), so this is an issue that might have to be tackled in vc-git.el... > You might want to take a look at `elpaa--select-revision` where I try to > solve this problem (for a slightly more restricted case, admittedly, but > it's already unsatisfactory). > > Maybe there's a better way to do that? Nothing immediate I can think of.