Re: [elpa] main 8f4cb59: * elpa-packages (counsel, ivy, swiper): Auto-sync.

[Basil L. Contovounesios]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Another option is to have separate manually-synced branches in the
>> upstream, one per ELPA package.  This is basically the same as what we
>> have currently, except that the manual syncing is done between the "main"
>> branch" and the "for-elpa branches" (all within the upstream repository)
>> rather than between the main branch in the upstream and the elpa
>> branches in `elpa.git`.  To me, it seems to bring no benefit, but
>> I guess depending on your workflow (and access rights) it could make
>> a difference.
>
> For better or worse I have access rights in both repositories, and I
> don't mind maintaining these branches in swiper.git.  To me, the main
> benefit of this would be not having to switch between different
> repositories for development or Git trickery, and then elpa.git would
> remain more declarative.  But ultimately I'm happy to do either.

I've now bumped all the swiper.git versions to 0.13.3, and merged the
upstream changes into the five corresponding branches in elpa.git.

The elpa-admin release detection doesn't seem happy with it though:
'make build/ivy' git-resets to the literal commit in swiper.git that
changed the Version header, which means it discards all the local
deletions etc. in elpa.git.  I attach a debug log of this in action,
where the presence of files from swiper.git that were meant to be
deleted in elpa.git causes the copyright check to barf.

The following seems to fix the revision detection locally:

>From 5d2120a287ae781e778e05383d8e8d223c49999d Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Tue, 9 Mar 2021 21:53:34 +0000
Subject: [PATCH] Handle merges when looking for release revision

For some discussion, see the following thread:
https://lists.gnu.org/r/emacs-devel/2021-02/msg01935.html

* elpa-admin.el (elpaa--get-release-revision): Follow only the first
parent of merge commits.  This handles cases where the Version
header is updated in a different branch to the current one, as is
the case with, e.g., ivy/swiper/counsel, whose external branches in
elpa.git have local deletions not present in the upstream.
---
 elpa-admin.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/elpa-admin.el b/elpa-admin.el
index 5cb3d261c5..17b3bb1bd4 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -170,7 +170,7 @@ elpaa--get-release-revision
                      (elpaa--call
                       (current-buffer)
                       "git" "log" "-n1" "--oneline" "--no-patch"
-                      "--pretty=format:%H"
+                      "--pretty=format:%H" "--first-parent"
                       "-L" (concat "/^;;* *\\(Package-\\)\\?Version:/,+1:"
                                    (elpaa--main-file pkg-spec))))
                     (buffer-string)
-- 
2.30.1

It seems to work with ivy and ivy-avy, which introduce releases via
merge commits, as well as dash, which doesn't.  WDYT?

Is there a better/different way?  The only alternative I can think of is
to enter revisions manually in the :version-map, but that doesn't seem
desirable in the long run.

P.S. Sorry if this breaks anything on elpa.gnu.org :(.

Thanks,

-- 
Basil

ivy.log
Description: Ivy build log