Digging around Github's git database API(swanson.github.com)

35 pointsby swanson15 anni fa11 comments

swanson.github.com

Digging around Github's git database API

http://swanson.github.com/blog/2011/07/09/digging-around-the-github-v3-api.html

2 comments

A few things: API v2 has a read-only object API: http://develop.github.com/p/object.html. Also, the blob content is returned in base64, because JSON does not handle binary data. It's not the raw loose object though. You're better off using the custom mime type.

The API v3 object API is meant to be extremely low level. If you want to update a branch with a new commit, you'll have to:

* Create new blobs for the added/updated files.

* Create updated tree objects. This can get tedious. If you update a file in /a/b/c, there's at least 3 new tree objects that you'll need to update.

* Create a commit that points to the tree at /.

* Update the reference for that branch.

Whew! It's pretty clear we need some higher level API around viewing and updating files, like the Gist API.

Thanks for the feedback!

schacon15 anni fa

> * Create new blobs for the added/updated files. > > * Create updated tree objects. This can get tedious. If you update a file in /a/b/c, there's at least 3 new tree objects that you'll need to update.

You can do it this way, but the tree API will also take deep paths and recursively write all the subtrees for you and just return the new highest level tree SHA. You also technically don't need to write the blobs first to get the shas, the tree API can optionally take a tree.content field instead of the tree.sha field if you want it to write the blob and update the tree automatically for you.

As for examples, I'll do a blog post soon with some examples and we'll probably add a slightly higher level API more like what Gist has. For now learning the fairly straightforward object model and writing some client level abstraction shouldn't be too difficult.

swanson15 anni fa

Thanks for the tip Scott, some examples would be awesome and much appreciated. I feel like I can make it work by stumbling around for a while, but in the end I'm more interested in building something that makes commits, not the actual git internals code.

swanson15 anni fa

Cool, I didn't see that object api in v2 -- I think I must have skipped the v2 release altogether. I just remember the green v1 site :)

So what is the binary data that is base64 encoded? How does it get 'converted' to the raw output? I'll definitely be using the mime type, but I'm curious about how it's generated on the server.

jevinskie15 anni fa

You can recover the original data by base64 decoding the content. It is strange though because the github API adds "\n"s to the content string that you have to remove before decoding.

swanson15 anni fa

Oh, whoops...brain fart. I was making things more complicated than they needed to be. Thanks!

justincormack15 anni fa

I nice high level open http api to git would be a huge benefit, as working with the native http api from js is not simple, and not needed for every use case. Ideally not github only...

swanson15 anni fa

The `git.js` project I mention in the post seems to be heading that direction. It's only a few months old so it's missing some important features, but it looks to be on the right track and works with any repo.

justincormack15 anni fa

I saw that but I meant a higher level http api, easy to use from javascript, like this github API sort of is. Something you could use with much less code than the git http transport. It is gret to implement the existing api but it is not an optimal api from the use case of a javascript client.

swanson15 anni fa

The new API methods are pretty cool. Anyone else working on a project with them?

xerxes200115 anni fa

I am currently working on my thesis in which I make extensive use of the github API. I am trying to do an empirical (hence the data from github) analysis of innovation in the open source community.