Re: ELPA contributions?

[phillip.lord@russet.org.uk (Phillip Lord)]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On 12 Oct 2015 1:44 pm, "Phillip Lord" <phillip.lord@russet.org.uk> 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.

When I first looked at ELPA, I didn't know about git subtree. I still
don't know how to check whether a sub-directory has been added with
subtree. I just assumed that sub-directories in packages where that --
just part of one big repo. Which is why I used the external branches.

>> 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.

I understand that. Although, the MELPA set up works quite well for
upstream contributions also. You can clone all the repos on MELPA with
two commands (and a fair bit of patience).


> 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.

And I am happy to work on the :external explanation.

Phil