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.
> * 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.
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.
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.
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.
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...
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.
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.
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!