We’re introducing calendar-based versioning for our REST API, so we can keep evolving our API, whilst still giving integrators a smooth migration path and plenty of time to update their integrations.
While at RubyConf this year, giving my talk and drinking like an idiot with nearly every internet-famous Rubyist out there, I had a great idea. Only my incredible humility prevents me from being able to properly describe the full awesomeness of this idea. While talking with some GitHub users there (which were many – there were tons of ‘Fork You’ sightings, and half the talks had a GitHub URL or Octocat in them at some point), I thought of a pretty useful addition to the github gem tool. So, I coded up a command line version of the network graph information, and it has since been pulled into the official github gem.
I also found out that not too many of the guys I talked to use the github gem, but of those that do, they seem to love it. So, yesterday I did a 20 minute screencast on how to use the github gem itself and our new network additions to it.
The long and the short of it is that the command line tool now has an interface to the network graph api – you can now view a list of all the remotes in your projects network that have commits that you haven’t pulled in yet, and you can list each of those commits and decide if you want to cherry-pick, merge or ignore them.
This gives everyone a nice, simple workflow to keep up to date on what patches people have pushed and be able to manage those changes easily. If you have a project or have forked a project that has a number of forks and want to see quickly and easily what is out there that you don’t have yet – this is going to change your life.
Even cooler, you can filter and sort the list of outstanding commits, including by whether or not each patch will apply cleanly to your current HEAD. You can literally have hundreds of patches pending from people and be able to see which of those hundred should cause you no merge conflicts when incorporating. That will let you contact the others and ask them to rebase their work off your current work before you will pull them in. For more details and examples, check out the screencast :
(you may want to fullscreen this to read all the command line stuff…)
On a side note, I tested this out in like 5 online video sites, and I have to say if you’re looking to put screencasts online where you need to be able to read fine text – blip.tv is basically your only choice. Seriously – that site rocks. If you click the fullscreen you can actually read everything, it’s not all pixelated and such. Youtube, Vimeo, Viddyou, Brightcove – nothing else worked. fyi…