dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

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

Attachment: signature.asc
Description: This is a digitally signed message part