On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
> And I don't agree that the project would be better off with something
> else, if it was, somebody would have proposed an alternative by now,
> but there aren't any. I have tried gitg, and giggle, and I have even
> contributed to them, but they are just not as good and useful as plain
> old gitk, I always keep coming back.
> * is blazing fast to start
> * doesn't have a lot of dependencies: just tcl/tk
> * works on Windows without a major fuzz
> * is actively maintained
> * shows a proper graph (unlike gitg or giggle)
> Now, show me an alternative that fulfills all these points. And I'm
> pretty sure you won't find one, because if you did, it would have been
> already proposed for mainline git... there isn't any. And if you did,
> we would start with oh, but it's GTK+, or it's Qt, and how do you make
> it work on Windows. No, gitk is just fine, and works great.
> Tcl/Tk might not be your cup of tea, and indeed it's rather unmodern,
> but that only tells you how an awful job the modern toolkits have done
> with regards to portability and flexibility.
> You were arguing for portability, well, Tcl/Tk works on all platforms,
> here, have a look, there's no other tool that fulfills this:
*cough* git-cola *cough*
it runs everywhere. Yes, windows too. It's written in python.
It's been actively maintained since 2007.
It's "modern" and has features that don't exist anywhere else.
It even has tests. It even comes with a building full of willing
guinea-pigs^Wtesters that let me know right away when
anything goes wrong.
It uses Qt but that's really the whole point of Qt -> cross-platform.
(not sure how that wiki page ended up saying Gnome/GTK?)
The DAG aka git-dag (in its master branch, about to be released)
is nicer looking then gitk IMO. gitk still has some features
that are better too--there's no silver bullet, but the delta
is pretty small.
The only point this doesn't fulfill is dependency-free-ness.
With that requirement the answer can *only* be tcl/tk.
So saying, "go look for one you won't find it" is really
a tautology. It's not even an entertaining one.
When the requirement is, "what is the best user experience
possible", then you use a mature GUI library. These are different
requirements and probably different use cases. For the gitk use
case, gitk is the perfect tool.
Anyways, just sayin', you make it sound like this stuff doesn't
exist, but it does. I've never proposed it for mainline
git because I'm very aware of the dependency requirements.
But, if git "recommended" it I would very much appreciate the
extra eyes and contributions. Being in mainline git could
possibly help with that. A submodule under contrib/
would be an interesting experiment.
In any case, I think documenting the python standards
(even if within contrib/ only) is a good thing.
We'd be increasing the overall portability by documenting
what we support and sticking to it, just
like what is done for shell scripts and perl versions.
Eric is helping make that happen, let's not throw
out the baby with the bathwater. FWIW, I would also make
my python expertise available.
This thread has gotten into meta-meta territory --
it's discussing code that has not yet even been written,
and going off on all sorts of tangents.
Let's stay on target. I think bringing up python
as an extension language would help in a these key areas:
- There are a few python modules floating around that
are similar to the ruby grit library. Having an official
python module would be good.
- Commands on the edges of the git experience (GUIs,
import/export/etc) can benefit from python. git-p4
is one example. git-weave is another.
Are there any arguments against it for these use cases?
BTW, Felipe, if you're going to be rewriting python code to ruby,
please, pretty please rewrite that darn GUI ;-)
You can call it "git-new-cola: project kansas"
I expect a patch by the morning ;-p
I kid, of course, but if you do pull it off I WILL buy you a soda-pop!
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html