Re: ELPA contributions?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

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

I really regret squashing: I think I only did it because of some vague
sense that it would be more hygienic. Fairly nonsensical, but I don't
think it's possible, or practical, to unsquash at this point. For the
sake of simplicity, I think it would be good if the README recommends
not squashing.

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