From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: ELPA contributions? Date: Mon, 12 Oct 2015 22:25:16 +0100 Message-ID: References: <87612g5tmx.fsf@fencepost.gnu.org> <87io6cl0hx.fsf@russet.org.uk> <87lhb8ulex.fsf@ericabrahamsen.net> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114014a62e96270521eef7db X-Trace: ger.gmane.org 1444685230 29291 80.91.229.3 (12 Oct 2015 21:27:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 21:27:10 +0000 (UTC) Cc: emacs-devel To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 23:26:58 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 1ZlkcU-0004Mg-7I for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 23:26:58 +0200 Original-Received: from localhost ([::1]:58869 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlkcT-0007UT-6T for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 17:26:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlkat-0005lE-82 for emacs-devel@gnu.org; Mon, 12 Oct 2015 17:25:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zlkar-0001Tj-SS for emacs-devel@gnu.org; Mon, 12 Oct 2015 17:25:19 -0400 Original-Received: from mail-lb0-x22d.google.com ([2a00:1450:4010:c04::22d]:36070) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlkar-0001Td-I7 for emacs-devel@gnu.org; Mon, 12 Oct 2015 17:25:17 -0400 Original-Received: by lbcao8 with SMTP id ao8so155866931lbc.3 for ; Mon, 12 Oct 2015 14:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hhF1KMaEGwJdKmsYUjHse0558jK6UfvC+2c5qZKhQP0=; b=DFReP9qrcFOkODgCoK15R2kst50ybjmFF0PbCHVSEJ3AqTHpYKFIdNh+O8T+DEjq84 Q9Mnc7zyxvf2gl3DrddPWQ9qRJojlZ4pLpfTGDooJYaaD1cUBurAjSe0PjNLwk1oyKJ6 Cs8EVE6yXYTkm/h3hfdjGPqDI5ZygjZmHBDeoNnMR1v2FwWYdJQfhIsL+Dsm+NLFyAc5 TrL7Oh6Kn+3CxNOVM1s6mv9y2crrEf93ykePTY2DuM4IMxHAHenbFkx9hQkOJGOPzmb7 ZD5I/qj5xNzjiyrE4IBAyJIt/Ldef/jF4u6CmwAXU8BpHgTbtAommm5GsARKDXuYcJaR i8/g== X-Received: by 10.25.150.199 with SMTP id y190mr8984599lfd.35.1444685116509; Mon, 12 Oct 2015 14:25:16 -0700 (PDT) Original-Received: by 10.25.27.78 with HTTP; Mon, 12 Oct 2015 14:25:16 -0700 (PDT) Original-Received: by 10.25.27.78 with HTTP; Mon, 12 Oct 2015 14:25:16 -0700 (PDT) In-Reply-To: <87lhb8ulex.fsf@ericabrahamsen.net> X-Google-Sender-Auth: AgTnYVPvli4lUVDmrLkQe5vG0Wk X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22d 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:191403 Archived-At: --001a114014a62e96270521eef7db Content-Type: text/plain; charset=UTF-8 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" wrote: > > 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 > > --001a114014a62e96270521eef7db Content-Type: text/html; charset=UTF-8

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
>
>

--001a114014a62e96270521eef7db--