Re: Windows support

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Jul 26, 2007, 07:52 UTC
Message-ID: <Pine.LNX.4.64.0707260841490.27738@beast.quantumfyre.co.uk>
In-Reply-To: <20070726071316.GE18114@spearce.org>

On Thu, 26 Jul 2007, Shawn O. Pearce wrote:

Show 26 quoted lines

> Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
>> 2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>> 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.

Show 8 quoted lines

> 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