From: Steven Grimm <koreth@midwinter.com>
Date: Thu, 18 Jan 2007 19:29:53 GMT
Subject: Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt
Message-ID: <45AFCAB1.8010903@midwinter.com>
In-Reply-To: <81b0412b0701180752x1664f661o17ce78a7024590f3@mail.gmail.com>

Alex Riesen wrote:
> I count 17 instances (excluding run_command). At least fetch-pack
> is not trivial (the sideband code. Could be done in a  thread, which
> is not portable just as well).

I looked at that briefly a while ago -- at the prompting of a Windows 
developer friend of mine who has some interest in git -- and it seemed 
like the best thing for portability to non-fork()ing systems would 
probably be a refactor. It looked to me like it'd be possible to 
reorganize the code such that it'd work all in one process with no 
threads or forking or anything. Not *trivial*, mind you, but possible. 
There's nothing in the code path that I saw (I didn't analyze it 
super-thoroughly) that looked like it actually needed to run in parallel.

IMO it's worth doing at some point post-1.5.0 simply because it means 
one less hurdle for someone who's looking to port Git to Windows. Plus 
it'll probably make the code slightly more efficient even on Linux and 
friends; there'd be less context-switching latency.

 From my brief look, that was the only nontrivial use of fork(). Almost 
all of the rest are simple fork/exec pairs.

Of course, the bigger hurdle for a native Windows port is all the shell 
scripts. Mercurial solves that by using Python for all its scripts, 
which at least has a native Windows version that can be installed. I 
wonder if git will/should eventually move its remaining shell scripts to 
Perl for that reason, Perl being git's de facto non-shell scripting 
language of choice.

-Steve