"Basil L. Contovounesios" writes: > Stefan Monnier 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: