emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELPA contributions?


From: Artur Malabarba
Subject: Re: ELPA contributions?
Date: Mon, 12 Oct 2015 22:44:13 +0100


On 12 Oct 2015 1:44 pm, "Phillip Lord" <address@hidden> wrote:
>
> Well, here is the interesting bit. As far as I can tell, a subtree IS an
> external (sort of).

Let's not get lost in semantics. ;-)
A subtree is a local directory, which _can_ be updated by pulling from a remote or can be edited locally. That's all there is to it. Call it what you will.

> AFAICT, for instance, "ack" is a subtree (which I
> think means, it has been added by the "git subtree" command, although I
> don't know how to test this), while "auctex" is a :external. But both
> are identified in externals-list. While ace-window is neither.

Most likely ack is listed there by mistake. But I'm just guessing here, can't check right now.

> All fairly confusing really. I've been using :external branches for my
> packages, but I think possibly I should have been using subtrees. I used
> to not use externals at all (i.e. neither an :external or :subtree), but
> that didn't work.
>
> The MELPA process (i.e. submit a recipe) is much more straight-forward.

True. But that wouldn't work for Gelpa. I believe the intention of the current model was that Gelpa code is part of Emacs, and so anyone who can make changes to Emacs should be able to make changes to Gelpa packages just as easily. Stefan can probably confirm or deny this.

Having everyone on the same repo is not the cleanest way to achieve this, but it's very doable and the disadvantages are acceptable.
A cleaner way would be to give each package its own savannah repo, but that's probably much less doable and not worth the trouble (though the technicalities of this are beyond me).

> Still, having said all of this, I have a workflow which works using
> :external branches, and which works whether or not you have commit
> access to the "main" repository. I'll try and write this up at some
> point. I'd love someone to do the same for subtrees, so I can see
> whether that would have been the right way to go in the first place.

If no one steps up, expanding the subtree explanation on the readme is on my todo list with reasonably high priority.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]