dulwich-users team mailing list archive

[David Borowitz <dborowitz@xxxxxxxxxx>]

Seeing Scott give an update on libgit2 makes me think we should consider it
for C optimizations for dulwich.

The big pro is that it's existing fast, reusable code for stuff we know
dulwich is slow for (commit parsing and pack inflating come to mind). I'm
happy to keep hand-rolling C optimizations, but they'll probably boil down
to roughly the same code that's in C git and now in libgit2. Seems like
wasted effort to me.

We wouldn't be sacrificing a moderately-optimized pure-Python
implementation, either. We wouldn't be using it to implement any new
functionality.

The big con is that it's a third-party dependency, which we've avoided thus
far. My counter to that argument is that this could easily be the *only*
third-party dependency we'd ever need.

Another open question is whether we dulwich devs should be involved in
developing Python libgit2 bindings, which will happen regardless of whether
we use libgit2 or not.