Re: [PATCH/POLL] git-format-patch: the default suffix is now .patch, not .txt

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 18, 2007, 19:57 UTC
Message-ID: <Pine.LNX.4.63.0701182053090.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <45AFCAB1.8010903@midwinter.com>

Hi,

On Thu, 18 Jan 2007, Steven Grimm wrote:

Show 9 quoted lines

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

Show 6 quoted lines

> 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