On Thu, 26 Jul 2007, Shawn O. Pearce wrote:
Han-Wen Nienhuys <hanwenn@xxxxxxxxx> wrote:
2007/7/25, Johannes Schindelin <Johannes.Schindelin@xxxxxx>:
Did you succeed in adding perl?
It is not that important, because I plan
to make git-gui the main user interface with this installer. But Junio
keeps adding Perl scripts (ATM add -i and remote) that I have to convert
later...
I don't see what this is good for.
What git-gui is good for? Its a GUI. For people who perfer to use
mice and push buttons over keys and a command prompt. A large number
of people in this world (many of them on Windows) like these things.
Me, I'm more command line than I am GUI, yet I develop git-gui.
So I find myself using it a lot, just so I can eat my own dogfood.
Or do you mean Dscho's other point about rewriting tools into C?
I would suggest to making a clear
decision of what are recommended languages, and move everything else
to contrib/ .. Currently, C and bash seem the most reasonable choice,
but you could decide for perl, but then the consequence should be that
the bash scripts are translated into perl. Having both bash and perl
serves no purpose, and will lead to duplication of library code to
interact with the git binary.
Well, that really doesn't make much sense from the Linux POV. Bash, perl
and C are all well supported languages, each with its own set of
strengths. The tools that are being written are true parts of git - not
optional contributed bolt-ons.
Admittedly it would probably increase the motivation to make everything
built in if only C programs were allowed outside of contrib - but git
would probably have not got where it is in that case.
Sure, but there's some stuff that shell is good at, and other stuff
that Perl is good at. Forcing everything into one mold while we
prototype new features is really limiting.
But both are slower on fork challenged systems than using native C.
Look at git-fetch for example; my ~400+ branch repository is taking
upwards of 5 minutes to run a no-argument, no-changes git-fetch in.
All sh and fork overhead.
I have a repo with ~9000 refs - it's what motivated me to start rewriting
fetch in C ...
times for fetch to decide there were no changes (on Linux, local XFS
disk):
pure-shell: ~45 mins
shell + C (fetch--tool): ~30 secs
pure C: ~0.5 secs
(the C version isn't the current version that Daniel has, but rather an
older incomplete version that I had got far enough to do that much - so
it may actually be slightly slower now ...)
--
Julian
---
If you want to travel around the world and be invited to speak at a lot of
different places, just write a Unix operating system.
-- Linus Torvalds
-
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
