Hacker News Reader

Comment by alexchamberlain | Hacker News Reader

I know this is Github, but... Rather than use the Github API, wouldn't it be more efficient to interact with Git directly? Libgit2 maybe?

View on HN

Dogfooding aside, the vast majority of the time is spent running tests and actually deploying the code. The time to hit the API to merge the commit is negligible in comparison.

Also, Janky and Heaven are both tiny apps that don't necessarily have access to the file servers.

But they are hitting the API to get the OID of the master ref as well?

Not having access to the file system is a fair excuse...

The merge API takes branches: http://developer.github.com/v3/repos/merging/

Github itself is a Github project, therefore using anything other than the API would be some code duplication. Merging, Pull-Requests, Branches, Issues: all this is already covered when using the normal API.

I'm sure it could be "more efficient" when having code explicitely for this purpose, but then again you have to maintain to different code bases which do the same.

You either maintain a codebase that calls out to the Github API or a codebase that calls out to Git? What's the difference?

Theres a lot of things you can do in the API that you can't do in git. For example, pushes exist in the API, but don't really within git.

> For example, pushes exist in the API, but don't really within git.

`git push`?

I was unclear, sorry. You can't tell what pushes have occurred in the past from a git repo, but you can with the GitHub API.

I don't get it... The API is built on top of `git`!

GitHub has lots of things that Git doesn't have. As well as recording pushes and making them available over the API, it records fork information, has concepts of users and organizations which dont exist in git, has pull requests, comments, and post-commit code review, an issue tracker, etc, etc, etc.

Reply on news.ycombinator.com