All I ever do is "remote add, subtree add, subtree pull" to add a new
package; or just subtree pull to update a package. This is pretty much what
you're doing, except I don't fetch nor squash.

When someone edits a package on the elpa repo, I just copy the changes over
to my remote (no git commands). It's just simpler this way.

All of this should really be better explained on the readme. I remember I
felt a little lost the first time I was doing it. If anyone would like to
document these steps a bit better I would be thoroughly grateful.

Best,
Artur
On 12 Oct 2015 5:00 pm, "Eric Abrahamsen" <eric@ericabrahamsen.net> wrote:
>
> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
> > Artur Malabarba <bruce.connor.am@gmail.com> writes:
> >>> and the README just contains the technical details of uploading
> >>> material to ELPA (it's not really clear when to choose an external
> >>> branch).
> >>
> >> Yes, that needs to be clarified too. The idea is to just use a subtree,
> >> unless you _know_ you want an external branch for some reason.
> >
> >
> > Well, here is the interesting bit. As far as I can tell, a subtree IS an
> > external (sort of). 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.
> >
> > 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.
> >
> > 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.
>
> Here's from my notes on how I'm supposed to merge the Gnorb package into
> ELPA. I started using git subtree because it seemed conceptually like
> the right thing. It turned out to be pretty complicated (because I
> didn't understand it well) and I still feel a sense of dread every time
> I go to update the package. I wish there were a simpler way.
>
> I added a local git repo as a remote ("gnorb") to the elpa repo. Pulling
> from the external repo goes:
>
> git fetch gnorb
> git subtree pull --squash --prefix=packages/gnorb gnorb master
>
> Pushing from the ELPA repo to the gnorb remote (I tried this because
> Stefan made some changes directly in the packages):
>
> git subtree push --squash --prefix=packages/gnorb gnorb master
>
> This is followed by an expletive-filled paragraph of notes. I'm not sure
> pushing to the remote ever actually worked. I also tried something
> called "split branch", which barfed several pages of output into my
> shell, to what end I'm still not sure.
>
> In the end, when I wanted to get changes from ELPA into my external
> repo, I think it worked okay to simply throw a patch over and apply it
> there. There's no actual correspondence between commit SHAs in ELPA and
> the remote, so simply having the files in the same state is good enough.
>
> But basically it felt like I was going to have to learn all of the
> internals of git to do this with any sort of confidence.
>
> Eric
>
>