dulwich-users team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

On Mon, 2010-10-25 at 16:36 -0700, David Borowitz wrote:
> 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?)
I guess it depends a bit on how close the libgit2 and Dulwich models
are. If we can avoid extra layer that'd be great, but I can see how it
would make sense for some folks to use something that is a thinner layer
on libgit2. Alternatively, we could modify either to be closer to the
other.

I've only really looked at the index bits in libgit2 so far and those
look pretty similar to Dulwich. 

Cheers,

Jelmer

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