How to create the tree for creating a commit?

[iamwilhelm]

I'm able to create a Blob, and I see a repository.createCommit call, which requires you to pass in a Tree. However, how do you create the tree for a commit? The createTree() call is not yet implemented.

However, I assume I should be able to do it by hand. And yet, I don't have access to the TreeEntry object to stuff the Blob object into. I also don't seem to have access to Signature for the commit as well. I assume it should look something like (in coffeescript):

repo = gitteh.openRepository('some/path.git')
refHead = repo.getReference('HEAD').resolve()

blob = repo.createBlob({ data: new Buffer("some data") })

// how to access TreeEntry?
treeEntry = new gitteh.TreeEntry({ name: "blob.txt", id: blob.id })

tree = new gitteh.Tree({ entries: [treeEntry] })

// how to get Signature?
commit = repo.createCommit({
  author: new gitteh.Signature({ name: "wil", email: "[email protected]" })
  parents: [refHead.target]
  message: "some commit message"
  tree: tree
})

And also, this seems like you have to recreate the entire tree in order to commit. That seems like a pain given that usually you just want to commit changed files. How do you commit changed files?

[samcday]

@iamwilhelm This is something I hope to address in the short-term with a v0.18.0 release. Hang tight, or feel free to contribute if you're able! :)

[iamwilhelm]

I had wanted to, actually. However, at the time, the repo was in the state where it didn't even compile (against node 0.6.12, and the docs didn't say which version I needed), so that was a high barrier of entry. In addition, you said you were refactoring at the time, so I wanted to wait til you were done.

It'd be easier for us to contribute in the future, if master always works, even if it's behind the edge! And make the refactorings on a different branch than master.

[samcday]

@iamwilhelm Understood. The refactor was necessary for gitteh to continue living, as prior to the refactor the native bindings code was getting pretty complicated. I will endeavour to keep master more stable (got Travis building and testing master now for example), but bear in mind the stable release tags are what should generally be used though!

[iamwilhelm]

@samcday So from now on, contribute by forking from the stable tags instead of master?

[samcday]

@iamwilhelm I don't think that would be strictly necessary - you're better off creating a topic branch for contributions off whatever the latest HEAD of master is. Of course when it comes time to submit it upstream you'll want to rebase your changes on top of whatever new stuff is available, and this may introduce merge conflicts to be dealt with. That said I'm happy with where the codebase is at, and won't be making any crazy refactors that render your contributions-in-progress worthless or anything :)

[FrozenCow]

I really wanted this feature too, so I made a pull request. Please check out #63