From: Artur Malabarba <bruce.connor.am@gmail.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: ELPA contributions?
Date: Mon, 12 Oct 2015 22:25:16 +0100 [thread overview]
Message-ID: <CAAdUY-+HhDHQeB4F4U0rxt_EiwEiV02bthn+ezO8Y4=TgUV5dw@mail.gmail.com> (raw)
In-Reply-To: <87lhb8ulex.fsf@ericabrahamsen.net>
[-- Attachment #1: Type: text/plain, Size: 3562 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 4493 bytes --]
next prev parent reply other threads:[~2015-10-12 21:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 8:32 ELPA contributions? David Kastrup
2015-10-09 22:42 ` Artur Malabarba
2015-10-10 6:55 ` David Kastrup
2015-10-10 7:00 ` David Kastrup
2015-10-10 22:24 ` Artur Malabarba
2015-10-10 22:26 ` Artur Malabarba
2015-10-12 12:44 ` Phillip Lord
2015-10-12 16:00 ` Eric Abrahamsen
2015-10-12 20:54 ` Phillip Lord
2015-10-12 21:54 ` Artur Malabarba
2015-10-13 9:27 ` Phillip Lord
2015-10-12 21:25 ` Artur Malabarba [this message]
2015-10-12 22:14 ` Eric Abrahamsen
2015-10-12 22:32 ` Eric Abrahamsen
2015-10-13 9:35 ` Phillip Lord
2015-10-13 11:30 ` Artur Malabarba
2015-10-13 17:38 ` Eric Abrahamsen
2015-10-14 11:14 ` Phillip Lord
2015-10-12 21:44 ` Artur Malabarba
2015-10-13 11:15 ` Phillip Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAdUY-+HhDHQeB4F4U0rxt_EiwEiV02bthn+ezO8Y4=TgUV5dw@mail.gmail.com' \
--to=bruce.connor.am@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=eric@ericabrahamsen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.