Stephen Cuppett <cuppett@xxxxxxxxx> wrote: > On 7/25/07, Steffen Prohaska <prohaska@xxxxxx> wrote: > > >Is it just that windows developer hate cygwin because it's to > >complex to install or is there any severe limitation? > >functionality? stability? performance? > > I actually have no problems with cygwin and find it works pretty well > with git repositories. Starting the xserver to run git-gui is pretty > annoying though. I've never even tried to run it that way. I know the Cygwin packages have two different Tcl/Tk binaries: one that is actually a hacked up native Tcl/Tk (which uses native Win32 graphics) and one that is a straightup recompile of the UNIX Tcl/Tk (which uses X11 only). I only have the native Win32 Tcl/Tk installed, and thus run native graphics. An advantage of the native Tcl/Tk is just that, its native. A downside is it is native. It doesn't use the Cygwin APIs for exec, it directly goes through CreateProcess(). It doesn't use the Cygwin APIs for file IO, it goes directly through the native Win32 stuff. Which means it sometimes has a difficult time with Cygwin paths. There are a few places in git-gui where I run `cygpath -w` just to handle this. I've also recently tested git-gui under the ActiveState Tcl distribution. It ran, but for reasons unknown to me (I didn't research it yet) the .git/info/exclude rules didn't apply when git-gui spawned a `git ls-files --others` helper process. I have considered doing a starkit of git-gui, msys based git executables/dlls, and the ActiveState Tcl engine. That should give users a single git-gui.exe that they can just download and launch, no installation required. Haven't started it yet, partly because I haven't finished removing the need for shell scripts to support git-gui. I'm almost there, especially with Daniel Barkalow's work on a native C fetch. > Windows-based development teams are going to expect > easy access to those kinds of tooling. Otherwise, the champion will > be pushing a type of workflow change that would hinder adoption anyway > and leave a sour taste for a long time. I agree. They also want this thing called "explorer integration" or something like that. I've never had good luck with cra^H^H^Hpackages that install themselves into the Windows explorer UI. I would probably never develop such a thing myself. > I don't know if the performance problems are cygwin or not. More > knowledgeable people might be able to answer, it's just what I'm > observing right now. It could be more fundamental to the types of > access being performed en masse on inode-based versus NTFS systems. As Linus described its NTFS/Windows that is horrid here, and not really Cygwin. Linux is just fast. Almost all modern UNIXes are. At least when compared to the Windows kernel running on a crappy 4500 RPM IDE drive that is also hampered with a virus scanner that wants to scan 12 GiB of data every 30 minutes, even when the volume has only 8 GiB of files on it. ;-) Git is fast. Its faster than SVN on the same hardware. Even under Windows. About the only thing that I think is "slow" is two areas: * status. Doing lstat() on 8,000+ files takes a little while. Hooking into the OS' native file monitoring facility and having that tell us which files are stat-dirty would reduce the need for these massive lstat() runs. * for-each-ref. Opening 400 ref files to read their current SHA-1 values is not fast on Windows. More aggressively packing refs (at least on Windows) may actually be worthwhile. Another option might be to have the same process that is watching the OS' file monitoring interface cache the ref values, so we can get to them via say shared memory or a pipe instead of file IO. Neither feature is really necessary on a good UNIX however, as most kernel development teams have just made sure their system has good file IO throughput. Oh, and they don't have to run virus scanners that get higher IO priority than everything else. -- Shawn. - 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
