johnmdonahue

GitHub API v3 everyauth Shim

johnmdonahue@gmail.com (John Donahue) — Tue, 12 Jun 2012 00:00:00 -0700

GitHub shut down API v1 and v2 today which will cause apps relying on bnoguchi/everyauth to fail. In lieu of a pull request or package update, here's a quick shim that overwrites the default apiHost and fetchOAuthUser.

var everyauth = require('everyauth')

everyauth.github

  .apiHost('https://api.github.com')

  .fetchOAuthUser(function (accessToken) {
    var p = this.Promise()
    this.oauth.get(this.apiHost() + '/user', accessToken, function (err, data) {
      if (err) {
        return p.fail(err)
      }
      var oauthUser = JSON.parse(data)
      p.fulfill(oauthUser)
    })
    return p
  })

Installing Node from GitHub

johnmdonahue@gmail.com (John Donahue) — Thu, 16 Feb 2012 00:00:00 -0800

Node already has an awesome installer as well as a few version manager options (creationix/nvm, visionmedia/n). But if you just want the flexibility to stay on the bleeding edge or install from a specific commit/tag of interest, building from GitHub is a great alternative.

Clone or fork the repo

$ git clone https://github.com/joyent/node.git
$ cd node

Select a tag or commit to build

$ git tag
v0.5.6
v0.5.7
...
v0.6.1
v0.6.10
$ git checkout v0.6.10

Build

$ ./configure
$ make
$ make install
$ node -v
v0.6.10

Post install, I like to put the seat back down and checkout master so it's primed and ready to let me quickly jump back in and grab the latest goodness.

$ cd node && git pull
$ git checkout badass-newness

Pull Request Basics

johnmdonahue@gmail.com (John Donahue) — Mon, 12 Dec 2011 00:00:00 -0800

I've dropped my share of git bombs and still do, so I know it can be a real pain in the ass — and a bit embarassing — to skip a rebase/pull/merge when working on a pull request, so here's a generic quick reference for the standard GitHub contribution workflow. Every project has it's own guidelines but this should cover the basics.

Fork

Fork the original repo on GitHub and clone it locally.

$ git clone git@github.com:you/repo.git
$ cd repo

Add upstream

Add the original repository as a remote named upstream. This gives you a to pull remote changes.

$ git remote add upstream git://github.com/original/repo.git

Branch

Create a topic branch. If your pull request is a new feature, you will probably need to work from a development branch rather than master. For example, many projects use a develop or *-wip branch for this. A hot fix on the other hand might make more sense targeted at master. The remaining instructions will assume master but it's important to make sure your work is branched from an appropriate commit.

$ git checkout -b feature-or-bug-fix

Hack away

Make your changes, add tests and commit.

$ git commit -am "fix the things"

Pull upstream

Checkout master and pull in any upstream changes. You should not run into any merge conflicts at this point since all work is being done on a topic branch.

$ git checkout master
$ git pull upstream master

Rebase

This is the fun bit. If there are conflicts between your branch and the pulled in remote changes, you will need to merge them. Merging is outside the scope of this post but it's a good idea to rebase regularly.

$ git checkout feature-or-bug-fix
$ git rebase master

Push

Push the topic branch to your remote fork.

$ git push origin feature-or-bug-fix

Pull request

Submit the pull request. As noted above, be sure that you target the appropriate branch — namely the one you branched from originally.