From: Julian Phillips Date: Thu, 26 Jul 2007 07:52:12 GMT Subject: Re: Windows support Message-ID: In-Reply-To: <20070726071316.GE18114@spearce.org> On Thu, 26 Jul 2007, Shawn O. Pearce wrote: > Han-Wen Nienhuys wrote: >> 2007/7/25, Johannes Schindelin : >>> 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