On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar <davvid@xxxxxxxxx> wrote: > On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> wrote: >> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces > > *cough* git-cola *cough* > > it runs everywhere. Yes, windows too. It's written in python. > It's been actively maintained since 2007. % sudo pacman -S git-cola error: target not found: git-cola http://aur.archlinux.org/packages/gi/git-cola/git-cola.tar.gz % makepkg ==> Missing Dependencies: -> python2-pyqt>=4.3 ==> Checking buildtime dependencies... ==> Missing Dependencies: -> asciidoc -> docbook-xsl -> rsync -> xmlto -> python2-sphinx>=1.1.3 Sorry, no. I'm not sure if you have been following, but msysgit doesn't seem to have good support for python, let alone Qt. In my view the fact that it uses python is not a good thing. > 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?) Yes, Qt is cross-platform *in theory*, but have you used any Qt application in Windows? I haven't. > 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. If you mean this one: http://1.1.1.5/bmi/git-cola.github.com/images/dag.png Then I wholeheartedly disagree. > 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. That's the whole point; there is nothing else. If there was something else, there would be something else. But there isn't. > 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. But those are not the requirements. > 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. A lot of stuff exists. And people use a lot of those. But they don't fulfill the requirements that I think gitk does perfectly. > 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. It might be, if somebody actually tried to submit the code. But I honestly doubt so. > 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. Nobody has argued that there shouldn't be guidelines for python code. What I have objected is to 'strict rules'. > 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. That is the point; why should we change the policy for code that hasn't been written yet? That's not how things evolve in git as far as I have seen. > BTW, Felipe, if you're going to be rewriting python code to ruby, > please, pretty please rewrite that darn GUI ;-) I would need to write a widget toolkit first =/ I think I'll pass. gitk is fine. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
