git works as a deployment tool, but not in all cases. It's useful to deploy code, but when writing Java or Go, you usually don't deploy the code, you deploy compiled binaries. Currently, tsuru forces you to deploy your code (you can create a git repository versioning the binaries, and do some local magic to compile your source, put it in the repository and push it - like creating a "deploy" target in your Makefile, but that's an ugly workaround).
In the future, tsuru will probably support other ways of deployment.
Yes, tsuru calls that services. They're behind an API. Enabling the deployment of services without API's is already in our roadmap, but we don't know when we will get it done.
The original motivation wasn't exactly that, but we changed it. At the first moment, we started an open source platform as a service based on Globo.com needs. That's why tsuru first supported EC2 instances. But that's pretty expensive: having 10 virtual machines for an app is not cheap, and does not fit in most company's budgets.
That's why we started implementing support for application containers, and we need to work on documentation and facilitate the life of people willing to deploy tsuru.
Sorry for our absense. This HN entry surprised us. We're aware that we need better docs explaining what tsuru is and it compares to alternatives like OpenShift and Cloud Foundry.
Currently, we're not running tsuru in any public cloud. We _hope_ that will change in the future :-)
When using the work-in-progress lxc provisioner, tsuru will behave like Mesos, but it's no that stable yet. First we worked on getting it working with EC2 instances, and now we are working on lxc and frontend integration.