unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Subject: Re: ELPA contributions?
Date: Mon, 12 Oct 2015 09:00:22 -0700	[thread overview]
Message-ID: <87lhb8ulex.fsf@ericabrahamsen.net> (raw)
In-Reply-To: 87io6cl0hx.fsf@russet.org.uk

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




  reply	other threads:[~2015-10-12 16:00 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lhb8ulex.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).