Wednesday, August 15, 2012

Fun with GitHub pull requests

GitHub pull requests are great for contributors.  They offer a very simple way to publicly post a patch against a piece of open source software and get feedback from the maintainers.  For various reasons, though, actually doing the merge of a pull request via GitHub's UI may not be the ideal thing for a project maintainer.  Reasons include:

* a policy of putting the commit through test prior to merging it

* amendment of a relevant issue ID to a commit message which lacks one (I've not done this to a contribution, but I've considered it)

* the pull request should be merged into a branch other than the one it was filed against

and I'm sure you can think of others.   So the first couple of pull requests that I accepted were a bit painful, because my process was:

* git clone the contributor's repo

* use git format-patch to export the patches

* use git am to import the patches

In particular, the git clone of an entire repo just to get a 5-line patch seemed like a tremendous waste of time and bandwidth, and I knew there had to be a better way.  Obviously github's website displays the diff associated with the pull request, so it has to be stored _somewhere_, right?

And of course it is.  For example, here is a pull request:

https://github.com/eucalyptus/eucalyptus/pull/3/

To see the properly formatted patch associated with it, simply drop the trailing slash and add ".patch":

https://github.com/eucalyptus/eucalyptus/pull/3.patch

It's worth noting that I found this via a link tag which exists in the source of the pull request page:

<link rel='alternate' type='text/x-patch' href='/eucalyptus/eucalyptus/pull/3.patch' />

So there's probably some code floating around somewhere to simply follow that link instead of knowing how to alter the url.  Anyway, I'm quite happy to have found this.  I'm not sure why there's not an obvious link to it in each pull request page.  I think it would serve project maintainers well.

6 comments:

  1. Check out hub, it's a cli for working with GitHub: http://defunkt.io/hub/

    ReplyDelete
  2. I think you're making a much bigger deal than it has to be.

    First of all you don't have to clone the remote repository anew. You can add another remote to _your_ repository:

    git remote add ${contributor} ${contributor_repo}
    git fetch ${contributor}

    Then if you don't want to use GitHub's web interface you can check its content with

    git log ${contributor}/master

    Finally instead of having to use format-patch and am, you can just use git cherry-pick with the commit id. And you can easily amend the commit message with git commit --amend.

    ReplyDelete
    Replies
    1. This comment has been removed by the author.

      Delete
    2. Flameeyes, you are almost certainly right that there are git commands that simplify my old workflow; I'm still a bit of a git newbie, and I really appreciate the tips. "remote add" is definitely more lightweight than cloning a repo and very useful. Still, that "fetch" downloads a couple of megabytes of data, versus a 1k patch file.

      Also, there are more reasons for using "format-patch" ... sometimes the patch gets attached to a bug in an issue tracker, or added directly to an RPM or DEB package as a temporary patch file, etc.

      Delete