From: phillip.lord@russet.org.uk (Phillip Lord)
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-devel@gnu.org
Subject: Re: ELPA contributions?
Date: Mon, 12 Oct 2015 21:54:46 +0100 [thread overview]
Message-ID: <87lhb7kdt5.fsf@russet.org.uk> (raw)
In-Reply-To: <87lhb8ulex.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Mon, 12 Oct 2015 09:00:22 -0700")
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> 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.
Hmmm.
Well, with dash, I've used an external branch. I've set up remotes like so.
elpa git.sv.gnu.org:/srv/git/emacs/elpa.git (fetch)
elpa git.sv.gnu.org:/srv/git/emacs/elpa.git (push)
origin git@github.com:magnars/dash.el.git (fetch)
origin git@github.com:magnars/dash.el.git (push)
pwl git@github.com:phillord/dash.el.git (fetch)
pwl git@github.com:phillord/dash.el.git (push)
Now, I have commit access to ELPA, but read-only access to github.
My workflow (which I normally do in magit, so the commands here are
approximations!) is something like this.
To get changes from github to ELPA,
git pull origin master
git push -v --dry-run elpa master:refs/heads/externals/dash
(without the dry-run!).
Then to get changes from ELPA back to github I do:
git branch fix/something-from-elpa
git pull elpa externals/dash
git push pwl
Then I can open a PR from pwl to dash, which gets merged in. The commits
all match up so the ELPA change gets pulled then pushed to github, then
eventually pulled then pushed from github back to ELPA, but it all works.
At least so far. I've done the last bit once so far. I have no idea what
to do if Magnar ever bounces a PR.
I use a similar workflow for pabbrev, except that I have write access
both sides.
> 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.
I share the same feeling. The bit that scares me is pushing to ELPA.
Everything else is disposable. If I pull the wrong thing (like
elpa/master) to local, then I can just delete and start again. If I push
the wrong thing to phillord/dash.el that's more of a pain, but not a
disaster. But if I push my local master to the elpa master branch
(rather than externals) I do not know what will happen, but I suspect it
will be bad.
Phil
next prev parent reply other threads:[~2015-10-12 20:54 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lhb7kdt5.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--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.