Re: git 0.99.7b doesn't build on Cygwin

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 23 Sep 2005, Davide Libenzi wrote:
> 
> If you have only to run diff/patch, just use the native Win32 CreateProcess().
> You abstract that on a git_exec(), and you use fork/exec on Unix and 
> CreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is 
> pathetic. They do all that work to give you a fork(), and you throw it 
> away with an exec().

CreateProcess doesn't work all that well, since we want to dup file 
descriptors around and close them in the child.

In general, CreateProcess() is a totally crap interface. I realize it's 
common (and especially in the VMS/Windows world it's how things are done), 
but hey, at that point it's better if somebody just waits until git is 
stable, and just makes a totally separate "git for windows" thing. The 
interfaces are certainly simple. There's no point in trying to maintain 
one tree.

However, vfork() really _is_ a nice interface. It's faster even on UNIX,
and at least in theory it should be possible to do an efficient vfork()  
implementation on top of crap like windows. Does cygwin support that well?

Yes, git uses lots of filesystem stuff, and they suck under windows. Maybe 
cygwin adds its own overhead, but from everything I've ever been able to 
tell, filesystem access sucks under Windows regardless of any cygwin 
stuff. Add to an already slow FS interface the fact that virus checkers 
tend to hook into it and make it _even_slower_, and hey, you have a truly 
sucky OS. 

But at least with pack-files, the filesystem access patterns are much 
less common. Opening one pack-file and mapping it gets the FS out of the 
way. So I don't think that's necessarily a huge problem.

		Linus