From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: ELPA contributions? Date: Mon, 12 Oct 2015 09:00:22 -0700 Message-ID: <87lhb8ulex.fsf@ericabrahamsen.net> References: <87612g5tmx.fsf@fencepost.gnu.org> <87io6cl0hx.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444667262 30442 80.91.229.3 (12 Oct 2015 16:27:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 16:27:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 18:27:33 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZlfwZ-00038i-Pv for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 18:27:23 +0200 Original-Received: from localhost ([::1]:56511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlfwZ-0003u8-7q for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 12:27:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlfWf-00008n-HH for emacs-devel@gnu.org; Mon, 12 Oct 2015 12:00:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlfWb-0003XC-AM for emacs-devel@gnu.org; Mon, 12 Oct 2015 12:00:37 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:35930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlfWb-0003Wu-4f for emacs-devel@gnu.org; Mon, 12 Oct 2015 12:00:33 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZlfWZ-0002Bb-5g for emacs-devel@gnu.org; Mon, 12 Oct 2015 18:00:31 +0200 Original-Received: from c-76-28-237-150.hsd1.wa.comcast.net ([76.28.237.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2015 18:00:31 +0200 Original-Received: from eric by c-76-28-237-150.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Oct 2015 18:00:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-76-28-237-150.hsd1.wa.comcast.net User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:vbHu5s4BGEwJbmHF9I4FS8elwgs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191365 Archived-At: phillip.lord@russet.org.uk (Phillip Lord) writes: > Artur Malabarba 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