Hi. Would you mind add a couple of lines in the README to document this method? Also, can you write a test for it?

I added some documentation to the README, but I don't understand your testing so I'd rather leave that to you.

@mushishi78 Just out of curiosity, what test framework would be more familiar to you? We're rewriting all of our tests using something like Mocha, Jasmine or Qunit; any feedback is quite welcome!

I'm more familiar with Mocha, but I also just didn't understand the tests. For instance, I looked at the test for listBranches as I assumed it would be similar:

    t.test('repo.listBranches', function(q) {
        repo.listBranches(function(err) {
            q.error(err, 'list branches');
            q.end();
        });
    });

Now I would have thought the if you listed the branches for this repo (michael/github) then you'd get 'master' and 'gh-pages' but you don't seem to be testing for that.

Plus, if I tested for all the forks of this repo, there would be like 349 different forks. I could then test if it got the first few, but that may change in the future with different people deciding to fork or remove their fork of the repo. So you'd need a test repo that'd been forked a few times, but most people wouldn't likely fork on their on volition.

@mushishi78 Ah, okay. Thanks, that's really helpful!

Currently, the calls to things like q.error(err, 'list branches') (Which is most of the assertions at present) are equivalent to something like should.not.exist(err) in Chai. Essentially, it's existence checking the error callback argument, and passing if it's undefined.

I'm rewriting all the unit tests in #248, any feedback is very much welcome! 😄

Closed in error; reopening.

I've added a basic test for this PR. Merging.