Re: git 0.99.7b doesn't build on Cygwin

From: Linus Torvalds <torvalds@osdl.org>
Date: Sep 24, 2005, 18:10 UTC
Message-ID: <Pine.LNX.4.58.0509241102450.3308@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.63.0509232220330.30718@localhost.localdomain>

On Fri, 23 Sep 2005, Davide Libenzi wrote:

Show 6 quoted lines

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