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.
_______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
