dulwich-users team mailing list archive

[David Borowitz <dborowitz@xxxxxxxxxx>]

On Mon, Jul 19, 2010 at 06:55, Matthew Daniel <mdaniel@xxxxxxxxx> wrote:

> On Mon, Jul 19, 2010 at 3:31 PM, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:
> > I didn't see Dave's request, but it might be worthwhile discussing the
> > place of bin/dulwich.
> >
> > The dulwich executable at the moment is just a trivial frontend for the
> > Dulwich library, used for testing. It was never really meant as a tool
> > to be used by end users. Personally I see Dulwich as just a python
> > library for accessing git files/protocols, and I hardly ever use the
> > dulwich binary (I always use Dulwich through Bazaar).
> >
> > Other people have suggested writing other UIs for Git in Python (both
> > command-line and graphical) on top of Dulwich and I'd like to help them
> > by providing whatever they need. I'm wondering though if a clone of the
> > standard Git command-line UI is useful and maintainable in the Dulwich
> > codebase itself or whether it is perhaps out of scope for the project
> > and better placed in a separate project.
> >
> > Thoughts?
> >
> > Cheers,
> >
> > Jelmer
> >
>
> Yes, I believe I understand the project's focus, and I hope that my
> contribution isn't seen as undermining that focus. I, too, mostly use
> Dulwich via hg-git. However, it is (imho) so perilously close to
> having the 3 or 4 primitive SCM operations one would require to use it
> to sync from Git repos (not _participate_ in them, mind you, just
> download from them).
>
> For example, there are a ton of Git-hosted projects that infrequently
> publish releases. If one wishes to stay abreast of development, then
> syncing a local Git repo is the only way. If we can lower the bar for
> participation in Git projects, that does two things: it raises the
> number of people who have the opportunity to participate (since, let's
> face it, mingw-git is a beast) AND it increases the utilization of
> Dulwich, which [in theory] will increase its quality over time.
>
> I would never target "bin/dulwich" as "a replacement for Git", since
> that is a moving target and a bit of a high bar to set. But, if the
> "testing tool" happens to include "working-copy status" and
> "checkout", then I think that can only help both audiences: the
> library maintainers for showing how to use the library for some common
> use-cases, and the "end user" audience who now has one more tool in
> their arsenal.
>
> I believe I hear your concern, and if you want me to back away from
> this, I will certainly do so.


I for one agree with you. I think we can make full
command-line compatibility with C git an explicit non-goal, while at the
same time making bin/dulwich look basically like C git for the few commands
we do support. FWIW, JGit takes the same approach to command-line tools.

Even if for whatever reason the changes you're making don't make it into the
official bin/dulwich (which I think is unlikely), we still appreciate any
improvements to the library :)


>  -- /v\atthew
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dulwich-users
> Post to     : dulwich-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dulwich-users
> More help   : https://help.launchpad.net/ListHelp
>