dulwich-users team mailing list archive

[David Borowitz <dborowitz@xxxxxxxxxx>]

On Mon, Oct 25, 2010 at 16:26, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:

> 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


Yeah, this is awesome. We do need to think a bit about where to draw the
dulwich/libgit2 distinction. For example, will the C-extension-using ShaFile
instances delegate to separate python wrapped libgit2 objects, or will
python wrapped libgit2 objects be drop-in replacements for ShaFile?

The argument for keeping libgit2 separate and using delegation within
dulwich is that some people might want to use libgit2 from python without
buying into dulwich's object model and hierarchy. (Or would they?)


>
> Right now it segfaults because libgit2 doesn't handle opening non-index
> files correctly. I'm going to file a bug upstream.
>
> Cheers,
>
> Jelmer
>