The tree(tree_out) function needs a pointer and this does not make any sense in the JavaScript world

Shouldnt that pointer be a nodegit commit object which then gets unwrapped?

Shouldnt that pointer be a nodegit commit object which then gets unwrapped?

No, as the wrapped git_commit object is already the thing that's calling the function.

Current libgit2 API:

var result = git_commit_tree(tree_out, commit)

Current NodeGit API:

// generated version
var result = commit.tree(tree_out)
// custom one written in lib/commit.js
commit.getTree().then(function(tree) {
  // use the tree
});

So as you can see, the generated NodeGit API already knows what the commit object is because that's the object that's calling the tree(tree_out) prototype function. However, it's asking for an actual pointer object to "output" the tree into which doesn't make that much sense in NodeGit's object-oriented API and merely duplicates the functionality of the custom one.

I guess there are technically three (or more?) things we can do here.

1. Remove the generated tree(tree_out) function as originally suggested.
2. Remove the custom getTree() function and fix the generated tree(tree_out) function to be a simple tree() promise callback.
3. Generate tree(tree_out) function privately but don't expose it into the public API and then replace the internal implementation of the custom getTree() function to delegate to the generated tree(tree_out) function.

This doesn't seem correct. Instead we should kill the getTree function and correct the descriptor for the git_commit_tree generated code. @rcjsuen

@implausible Thank you for your comment.

Should git_commit_tree become a commit.tree() JavaScript function or should it be massaged to generate a commit.getTree() instead?

@implausible The new change that I've pushed kills commit.getTree() outright and replaces it with commit.tree().