Skip to content

Receiving contributions to your Github project

January 4, 2010
tags: , ,

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.

github-builder-graph

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?

git remote add defunkt git://github.com/defunkt/grit.git
git fetch defunkt
git merge defunkt/master

from → Programming
2 Comments leave one →
  1. anon permalink
    January 4, 2010 9:56 pm

    Keep your commit history flat. Rebase instead of merge. http://blog.woobling.org/2009/08/git-rebase-for-impatient.html

    Reply
    • draegtun permalink*
      January 5, 2010 4:26 pm

      Many thanks for info (had seen Nothingmuch post before but it slipped from mind).

      So I should have done:

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

      NB. Above is one line but may have word wrapped.

      I’ll give that a try next time. That and also perhaps try the Github “Fork Queue” apply option.

      /I3az/

      Reply

Leave a comment