my ramblings on life, work & anything left in-between

Receiving contributions to your Github project

Received my first ever contribution to one of my Github projects today. A pull request from a cpanservice? And I wasn’t the only one or was wondering who this cpanservice is or was?

I suspect that this as something to do with the recent gitPAN upload to Github and therefore is probably some automated service that is going through related projects making sure that Github CPAN projects do have the meta repository tag populated in the build process.

NB. I blogged about this repository link back in May but forgot to put my changes live. *blush*

This contribution was the necessary nudge I needed to find out how to use git to merge in external changes. Github itself did seem to provide a web option to apply this change directly under “Fork Queue”. However I wanted to do it all via git so first place I looked is the Github documention on pull requests.

My local directory was up-to-date so I just needed to do the following to pull & merge into my code:

git pull git://github.com/cpanservice/builder.git master

All merged and committed (see PS). Quick check of diffs & logs and then just needed to populate it back to Github:

git push origin master

You will see cpanservice changes immediately in the commits. However the Github graphs and fork queue take a little while to be updated to show the merge.

/I3az/

PS. The merged cpanservice changes showed up under me in the network graph (see red line below) despite showing up correctly under commits.

I think this is because I merge changes locally and then pushed back to Github? Its not an issue for these cpanservice changes but I would like to get it right for “proper” contributors.

So I think the alternate merge example documented by Github might be the better approach?

About…..

My name is Barry Walsh. I'm a freelance IT consultant from London, UK. [more]

This blog is mostly about Perl programming because this is what I use and love (and occasionally hate!) for the majority of my working (and sometimes non-working) day.

Occasionally I will touch on other subjects like PostgreSQL, Mac OSX, UNIX, Linux, Ruby, jQuery, Javascript, XML and many more techie things that I also play with regularly. Other non techie aspects of my life may slip in now and again but I'll try and keep that to a minimum because its normally boring anyway :)