Hi, On Thu, 18 Jan 2007, Steven Grimm wrote: > 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. ssh transport comes to mind, as well as paging functionality. Sometimes we fork() to catch out-of-memory errors more gracefully. > 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. Yeah, sure. We had no problems with Perl ;-) Seriously, IMHO bash is a smaller dependency: here you can at least rely on which extensions are present (none), and which path-name munging is present on Windows (/c/windows). No, the best is not to migrate shell scripts to Perl, but to C. Ciao, Dscho - 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