Re: elpa.git and `new-master`

[Jonas Bernoulli <jonas@bernoul.li>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> As part of the effort to setup the NonGNU ELPA infrastructure, I've also
> overhauled the GNU ELPA part.

Thanks a lot for your work on this!

>   As a result, I decided to create a fresh `new-master` branch which
>   doesn't share its history with `master`.  This new branch will replace
>   `master` in the coming days.

Since you have to do this for this branch anyway, please also force-push
to 'externals/transient' in order to discard the last few commits, which
were only needed because the `:renames' property did not exist yet.  Now
that that is available, I plan to use transient's "master" branch and do
the edits using `:renames' et al.

>   So whoever is tracking `master` will be faced with a
>   "non-fast-forward" update.  This can be annoying and I apologize in
>   advance, but I think the long terms advantages largely make up for
>   the short term annoyance.

I noticed that non-fast-forward pushes are disallowed (when trying to
do the reset I just mentioned myself) and ended up wondering if there
are any other checks in place that prevent other potential push errors.

Most importantly what happens if someone has managed to merge the old
"master" into the new one and then pushes that?  That is a fast-forward,
though one that we very much want to prevent.  Is there some list with
disallowed hashes?

>   - It also know how to generate Info files from Org manuals.
>   - It can even run `make` as part of building the tarballs, making it
>     possible to perform various massaging.
>     This obviously can't just run "anything you like" since it depends
>     on what's available on `elpa.gnu.org`, so if you want to use this
>     feature, please get in touch with me so we can coordinate it.

I had some issues with this.  Some of them are due to my packages
needing some additional libraries to generate the *.texi files from the
*.org input and I will contact you about that privately.  But there was
also one issue that might affect others:

`org-texinfo-export-to-texinfo' may end up calling git (e.g. to get the
version number), which requires access to the git (control) directory
"ELPA/.git" (just "ELPA/.git/worktrees/<package>" probably won't do),
but currently bubblewrap is not given access to that.

> - Another advantage is that the new code makes it much easier to build
>   your own tarballs, for example to test them before pushing to code.
>   You can just do `make build/[PKGNAME]` and the resulting package will
>   be built in `archive/[PKGNAME]-[VERSION].tar.

That almost worked. "make build/<package>" (or `elpaa--make-one-package')
calls `elpaa--external-package-sync', which pulls.  That of course is not
desirable when one wants to test some other revision of the package than
what would end up being pulled.

     Jonas