Cool, that sounds like a great improvement!

First, please revert any changes that are only whitespace - it seems like a bunch of those snuck in. This will help avoid unnecessary churn.

Second, I think that a more straightforward change would be to give git_treebuilder its own git_buf that it reuses - that will ensure that all users of the treebuilder get this improvement, not just git_tree__write_index. Does that seem reasonable?

Small nit on the commit message itself: please try to keep the initial line short, as otherwise many git commands become hard to read (e.g. git log --oneline). I'd propose something along the lines of

treebuilder: use shared buffer for writing trees

The function to write trees allocates a new buffer for each tree.
This causes problems with performance when performing a lot
of actions involving writing trees, e.g. when doing many merges.
Fix the issue by instead handing in a shared buffer, which is then
re-used across the calls without having to re-allocate between
calls.

And I agree with @ethomson on that it would be nicer to have a buffer at the treebuilder itself which would be reused for other functions, as well.

Anyway, this heads in a good direction. Thanks for contributing :)

Placing the buffer on the builder is a bit tricky, I think. write_tree creates a new treebuilder each call and only calls git_treebuilder_write once with it, so I don't think just that change would reduce the allocations. The builder can't be shared across write_tree calls because of the recursion in the loop.

I could put the buffer on the treebuilder, but I'd have to manage the buffer the same way I do now and just set bld->buf in write_tree. That doesn't seem better though.

Aha - thanks for clarifying, @mitesch - obviously you're quite right and I didn't understand the lifecycle there when I was re-reading it.

In that case, yes, I think this is great. @pks-t 's correct about our style - we follow the kernel / git styles. If you wouldn't mind squashing a fixup commit that matches the style, that would be great!

Mostly some style/nomenclature comments, but overall it's looking good. It might be worth making this part of the public API so external users of this function can make use of it as well.

The tree update might also benefit from doing something like this, which is another semi-heavy user of this.

Pushed a fixup with most of the requested changes. I'll squash once everything is 100%
Couple things still open:

• Where the initial buffer growth should be.
• Should I make this part of the public API?

@ethomson @carlosmn squashed and should be good to go

@ethomson @carlosmn Updated, sorry for the delay. I moved the definition to include/git2/tree.h. Let me know if the documentation is sufficient.