← Back to team overview

dulwich-users team mailing list archive

Re: bin/dulwich improvement

 

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.

  -- /v\atthew



Follow ups

References