dulwich team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

Hi Sebastian,

On Sun, 2010-04-25 at 09:18 -0700, Sebastian Thiel wrote:
> Thanks for bringing this up - license-related implications were not a
> major part of my thinking yet. One part of dulwich which influenced
> the respective git-python implementation is the handling of index
> files. I ended up rewriting and adjusting plenty of existing git-
> dulwich code as it couldn't be used one-to-one. Nonetheless, it was a
> major source of inspiration and saved a lot of time as details have
> already been figured out by dulwich.
Thanks, great to hear it has come in useful.

> Before spending any time on enhancements regarding the way git-python
> handles things, its worth thinking about how dulwich would or could be
> used. One feasible option could be to add dulwich as dependency, but
> it would require a license change on either side which in fact might
> be a show-stopper.
> The other option would be create an own implementation based on
> dulwich which is what I have partly done already (->index handling).
> The question arises whether the latter option is legitimate.
Copying code would probably be problematic, but looking at the Dulwich
code to learn how things work should be fine (but I'm not a lawyer,
etc).

> To my mind, it would be more beneficial for dulwich if it would be
> used as a submodule by git-python. Having git-python as a 'client',
> dulwich's code would not only be tested and used in possibly different
> contexts, it would also be possible to improve its interface as git-
> python brings in a different perspective. In a way I could imagine
> that git-python maintains its own patch-queue on top of the latest
> dulwich branch, patches which could subsequently be integrated into
> dulwich if feasible.
This would work for me, though I wonder what things git-python aims to
implement that Dulwich does not? What would there be left for git-python
to do?

Cheers,

Jelmer

> On Apr 24, 4:12 pm, Jelmer Vernooij <jel...@xxxxxxxxx> wrote:
> > Hi Sebastian,
> >
> > On Fri, 2010-04-23 at 07:31 -0700, Sebastian Thiel wrote:
> > > Thanks for sharing this information. So far, I have been looking at
> > > git-dulwich for functionality like reading packs, but its good to know
> > > there are alternatives.
> >
> > Please note that dulwich is GPL-licensed. You would have to get code
> > relicensed before it can be included in a project that is BSD-licensed,
> > such as git-python (or relicense git-python to something
> > GPL-compatible).
> >
> > I'm usually happy to relicense my code under the BSD license if there
> > are good reasons (avoiding duplicate work in git-python is a good enough
> > reason), but I'm only one of the copyright holders for Dulwich.
> >
> > Cheers,
> >
> > Jelmer
> >
> >
> >
> > > On Apr 23, 9:35 am, Govind Salinas <govindsali...@xxxxxxxxx> wrote:
> > > > Hi Folks,
> >
> > > > I got a bit lazy and discouraged and stopped working on Pyrite a long time
> > > > ago.  I have been thinking about starting up again, possibly leveraging
> > > > GitPython instead of my own implementation.  Part of my problem before was
> > > > trying to do too many things at once.
> >
> > > > In any event, I saw the GitPython roadmap and noticed you mentioning reading
> > > > git objects and packs directly.  I have working pack, index, loose object
> > > > reading and an object cache already done in Pyrite if you want to lift it.
> > > > The branch I am pointing you to is a bit of a mess, but the files relating
> > > > to python git-db reading are in good shape.  A couple of things are missing
> > > > form the index, such as making commits from the index (which you probably
> > > > don't care about) and using the index extension that helps keep track of
> > > > changes to make stating/diffing faster (which you probably do care about if
> > > > you want it to resemble native git-db reading performance).
> >
> > > > You can take a look here
> >
> > > >http://gitorious.org/~blix/pyrite/blixs-clone/trees/f27df895f477e4a9e...<http://gitorious.org/%7Eblix/pyrite/blixs-clone/trees/f27df895f477e4a...>
> >
> > > > The main files you want are going to look at are...
> >
> > > >http://gitorious.org/~blix/pyrite/blixs-clone/blobs/f27df895f477e4a9e...<http://gitorious.org/%7Eblix/pyrite/blixs-clone/blobs/f27df895f477e4a...>http://gitorious.org/~blix/pyrite/blixs-clone/blobs/f27df895f477e4a9e...<http://gitorious.org/%7Eblix/pyrite/blixs-clone/blobs/f27df895f477e4a...>http://gitorious.org/~blix/pyrite/blixs-clone/blobs/f27df895f477e4a9e...<http://gitorious.org/%7Eblix/pyrite/blixs-clone/blobs/f27df895f477e4a...>http://gitorious.org/~blix/pyrite/blixs-clone/blobs/f27df895f477e4a9e...<http://gitorious.org/%7Eblix/pyrite/blixs-clone/blobs/f27df895f477e4a...>http://gitorious.org/~blix/pyrite/blixs-clone/blobs/f27df895f477e4a9e...<http://gitorious.org/%7Eblix/pyrite/blixs-clone/blobs/f27df895f477e4a...>
> >
> > > > The way I have it set up, the object cache is needed to access packs,
> > > > because there may be multiple packs and the cache knows about all of them.
> >
> > > > I have been away from this for over a year, but if you have any questions or
> > > > if something doesn't work for you, let me know and I will see if I can help
> > > > out.
> >
> > > > Thanks,
> > > > Govind.
> >
> > > > --
> > > > You received this message because you are subscribed to the Google Groups "git-python" group.
> > > > To post to this group, send email to git-python@xxxxxxxxxxxxxxxx.
> > > > To unsubscribe from this group, send email to git-python+unsubscribe@xxxxxxxxxxxxxxxx.
> > > > For more options, visit this group athttp://groups.google.com/group/git-python?hl=en.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "git-python" group.
> > To post to this group, send email to git-python@xxxxxxxxxxxxxxxx.
> > To unsubscribe from this group, send email to git-python+unsubscribe@xxxxxxxxxxxxxxxx.
> > For more options, visit this group athttp://groups.google.com/group/git-python?hl=en.
>