On Mon, Jul 19, 2010 at 06:55, Matthew Daniel <[email protected]> wrote:
> On Mon, Jul 19, 2010 at 3:31 PM, Jelmer Vernooij <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~dulwich-users > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~dulwich-users Post to : [email protected] Unsubscribe : https://launchpad.net/~dulwich-users More help : https://help.launchpad.net/ListHelp
