Re: Python extension commands in git - request for policy change

On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

I suppose you are talking about BUILT_INS, and SCRIPT_FOO, but tcl scripts don't need no SCRIPT_FOO stuff, because they don't need to be regenerated, in fact, I don't think the shell scripts need to be regenerated, but that's not important, what is important is this:

all::
ifndef NO_TCLTK
	$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
	$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif

Why are you ignoring that?

According to whom?

I find it very curious how you are arguing for a change in the status quo to move more towards python, and the basis you are using for choosing python, and not ruby, or other scripting language is precisely the status quo. However, the only scripts using python are these:

SCRIPT_PYTHON += git-remote-testgit.py SCRIPT_PYTHON += git-p4.py

I already re-wrote git-remote-testgit in bash, and it's dubious whether or not git-remote-testpy (the new name for this old test) will fulfill any service. Than means 43% of the current python code is gone.

And what happens if I rewrite git-p4 in ruby? Would you then argue that ruby is the way to go because 1% of the *current* code-base uses it?

Interestingly, according to Wikipedia git is written in: C, Bourne Shell, Tcl, Perl. That seems to be the case.

As I said, gitk is integral to the git experience. Of course you are free to disagree, but according to the last user survey 57% of the responders used some kind of graphical tool (e.g. gitk, tig). How many use gitk, and how many use something else, we don't really know, but what we know is that gitk is distributed *by default*.

Nobody is arguing that gitk should not be distributed by default, just like nobody is arguing that git-p4 shouldn't, but we *know* very few people use git-p4 (1% according to the survey), and we can reasonably assume that many more use gitk.

You cannot have your cake and eat it at the same time. If you use the amount of code as a measure, then you have to agree that Tcl/Tk is a way bigger language than python in the mainline git world. If not, then by all means, show us the numbers. But you can't say "the important languages are A, B, and D, C doesn't count because I don't like it, and E doesn't count either because we should draw the line at three", that seems awfully convenient to push your agenda.

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.

gitk:
 * 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:

http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces

Isn't that what you are doing by triumphantly pointing at git-p4?

Sorry, if you want to cut the line for the languages that git should use right now at three, then python is out. Maybe in a couple of years. Maybe. But I doubt it.

Cheers.