I don't really see the point of including promises. Can't this be done in a separate module for example? I bet most of the people just want to use callbacks.

+1 for promises

I'm not looking to start a debate, I am just suggesting to use what Node uses by default (callbacks), and leave this option as a wrapper into a separate module (named like promised-nodegit for ex). I think that would be best for everybody.

@alessioalex Generally I would agree, except for the case of flow control. Promises are a fundamental building block and are coming to the language proper. This is a start to an unobtrusive and alternative approach to harmonize them with this library.

At the moment all asynchronous functions return undefined, a useless value. This PR attempts to leverage this known to always return a Promise. This is 100% optional. If you want to use callbacks and are happy with them, you don't need to modify your code. You don't have to know the return value even exists.

Without promises:

git.Repo.open(".git", function(err, repo) {

});

With promises:

git.Repo.open(".git").then(function(repo) {

});

I'm just curious what happens with:

git.Repo.open(".git", function(err, repo) {
  // cuz why?
}).then(function(repo) {
  // because you happen to have both a callback and use it as a promise?
});

Both would be triggered as it only augments the return value, not the original signature.

This has another added benefit of greatly simplifying the install process that is now based on Promises.

Since this doesn't remove the ability to use Nodegit with callbacks as before, I think it's a really good addition. I agree with you guys.

Blocked by #162 need more accurate isAsync information.

No longer blocked since we have a 100% accurate definition file. This is ready to merge.