How to check out a pull request for testing

A pull request ("PR") represents a request to merge a git branch into one of Elgg's version branches. To test it you need to check out the PR branch into your local Elgg install.

First, determine which version the branch is for. You don't want to put master branch code into your 1.12 development system and vice versa. Let's say the PR is for 1.12

cd ~/htdocs/elgg112

Now you can just fetch the PR branch from github directly. E.g. for PR #123:

git fetch origin pull/123/head:pr-123
git checkout pr-123

You're now ready to test!

  • Very nice article, but I would rename it to "How to checkout pull request for testing".

  • BTW, if you use get-pull-request and try to checkout branch names with "#" in them, you'll need to use my patched version

  • Personally I prefer manual version to better control what's happening with my repo. BTW it works well but you have to be careful when modifying the entry. In my case ELgg's original repo is named 'upstream' so I had to use

    fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*

    for not making mess in my refs.

  • Other methods for checking out PRs:

  • @Srokap I changed the guide to use the dead simple method mentioned in the gist comments. Requires no mucking with .git/config or other tools.

  • @Steve: Around the topic. It's hard to notice recent absence of most of the Core Devs and still it's my observetion that's there's lot's of pull requests on github and I imagine that around 50% of them could be pulled in with minor alterations. Also it's hard to ask you guys to spend more time on it. So while thinking of how to make things easier here I thought of making server that would automatically run core unit tests (and possibly to sth more) on new pull requests. Would you guys benefit from such solution or it's not worth the time?

    Additional help could be to give people from community some protocol of testing pull requests (from other developers) and give you some feedback so you (core devs) could rely on it to some point. I.e. follow instruction above to get pull request, run unit tests, review additional stuff, include your remarks/opinions, give report of what you did in sort of uniform format. This way we could minimize impact of you guys not always having much time for elgg (which is completely normal) on speed of Elgg development itself.

    I'm also thinking for some time now of making on my own some server that could to some level automatically upgrade old plugins (i.e. most of the migration 1.7->1.8 is possible with RegExps) or find bugs/bad practices in the code. The idea is to help in continuing development of abandoned code (by organizing it to some standard) or at least testing for some common bugs/bad practices/version compatibility. It's quite complex thing of course.

    Any way I'm wondering if working on/introducing such things could be useful.

  • auto-coder for 1.7 - 1.8 ? ;-P
    it's been a while..
    i remember the general interest being piqued then;
    but sometime later..
    lost interest in public development;
    just continued firther work on my token-parser,
    reflection driven utlities to achieve some level of 'smart' code
    scanning (which means real table-driven parser of php grammar)
    to enable more detailed analysis of elgd-related code
    for documenting ot building 'code-changers' upon.


  • @Dhrup: Very interesting project. Did you try to automatically check plugins from community with it to do some statistics?

    It's also not clear to me how many rules does your system has and how they're defined? Is there a chance to see the code somewhere?