On Mon, 2010-10-25 at 15:13 -0700, David Borowitz wrote: > 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. I think that's a reasonable tradeoff. It means somebody who wants to do a quick Dulwich project can still just check it out and get it to run. Right now having a C compiler is already a dependency for getting the C extensions to run (nontrivial on *nix, but it's a fairly high barrier on Windows). > 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. GMTA. I started hacking on this a bit to see how feasible it was when we had Scott on the big screen. My initial work is here (separate repository because bzr doesn't support colocated branches yet... ): http://git.samba.org/jelmer/dulwich-libgit2.git/?p=jelmer/dulwich-libgit2.git;a=summary Right now it segfaults because libgit2 doesn't handle opening non-index files correctly. I'm going to file a bug upstream. Cheers, Jelmer
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
