Re: Windows support

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jul 26, 2007, 07:13 UTC
Message-ID: <20070726071316.GE18114@spearce.org>
In-Reply-To: <f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com>

Han-Wen Nienhuys <hanwenn@gmail.com> wrote:

Show 9 quoted lines

> 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?

Show 7 quoted lines

> 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.

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.

-- 
Shawn.