Thread (32 messages) flat view 32 messages, 12 authors, 2016-06-15

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

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:42:49

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help