Re: Windows support

Steffen Prohaska <prohaska@zib.de> wrote:

It is just as rock solid as it is on Mac OS X (my real Git development system) and Solaris. If your Cygwin DLL does not support pread() you do need to compile with NO_PREAD=1, but that's a minor issue. Personally I build Git on Cygwin with pread() and mmap() enabled and it runs fine. Of course we only use it on local drives, and only on NTFS drives.

As has been stated already, Git's checksums work nicely to make
sure data hasn't been corrupted.  I've seen one user have trouble
with checksums failing in his repository.  Usually he recopies it
from another user and picks up where he left off.  Twice I've seen
his packfile corrupted and Git caught the corruption.  We seriously
suspect some bad blocks on his drive.  But budget says we cannot
replace the disk for another 4 years.
 

Its not that Cygwin breaks. Its that sometimes pressing Ctrl-C doesn't actually stop the process, e.g. the signal isn't sent or just gets ignored. So its annoying because you can't abort things as readily as you might on a good UNIX. Sometimes you get weird stack traces from a Git process when you Ctrl-C it. But I also see this same garbage out of a native Windows JVM when I Ctrl-C it from a Cygwin bash. Its just general Cygwin-ism or something.

Despite those failures I've never seen that stack dump actually
corrupt Git data.  Think about it.  Git needs to be safe on any
platform, even if the running Git program terminates unexpectedly
in the middle of an operation, such as because of an OOM from the
kernel, or an angry admin `kill -9`ing it.  So this little stack
spew is just annoying more than anything.
 

I *never* reboot my Windows system at day-job. Except when our local adminstration staff shoves some Microsoft uber-patch down onto our systems and that patch forces us to reboot the machine. So I never reboot for Cygwin (or Git's) sake. Ever.

Still true. Network drives have some issues as the SMB protocol doesn't support everything nicely. NTFS locally is fine. FAT32 has issues with mmap() not being well supported. If you must use FAT32 compile Git with NO_MMAP. Which is the default on Cygwin, as a lot of people still use FAT32.

This is true. Git doesn't like getting file names with case only differences on such a platform. E.g. just today I wanted to do the following:

  git mv foo.c Foo.c

but had to instead do:

  git mv foo.c CRAP && git mv CRAP Foo.c

because the former won't work on a filesystem that ignores case. I have the same problem on my Mac OS X HFS+ volume as it also ignores case.

Both of these are still true. git-gui on Windows suggests a repack if you have ~256 loose objects, on UNIX platforms it suggest a repack at ~2048 loose objects. The problem is really just a performance issue, the more files we have to open to access data the slower things go. The loose objects tend to be the really recent stuff (that's why they aren't packed yet) and the really recent stuff tends to be what is accessed most.

Opening 200 files takes time on Windows. Its just a limitation of the OS apparently. And its a fundamental property of the Git object store that we always write to loose objects first, as its fast and easy to make safe.

Another aside to this is `git grep --cached` or `git grep ... TREE` is *always* faster for me then grepping the working directory. The first two will return nearly instantly (tiny lag) while the working directory grep will take days. On Linux and Mac OS X the exact reverse is true, the working directory grep is usually faster if the disk cache is hot.

Yea, we've had some issues with that. This comes from one particular user (Alex Riesen) who uses Cygwin but for strange reasons is not allowed to use the Cygwin perl and instead must only use the ActiveState Perl. We've had some issues in the past with our Perl scripts running on that perl port. Alex has fixed many of them, but some may still be lurking.

Already talked about above.

We currently default core.fileMode to false on Cygwin, for this very reason. We used to not do that. We got smarter and realized that although Cygwin itself (and all Cygwin tools) will properly handle the executable bit on NTFS native Windows tools (e.g. Eclipse) won't. Users use the native Windows tools, then blame Git. So we disable it.

Oooooh. I did not know this tip. I still just cuss at Cygwin anytime I want to suspend a job and cannot.

See the crlf feature in gitattributes. You can now have Git create working tree files in CRLF format, but check them into the object database with only LF.

I think binary mode is the default now on Cygwin. It used to not be. Because of this problem.

Yea, sort of. I'm using about 180M (fully packed as best as I can make Git do) and its fine. I don't know what a definition of "big" is.

This I can't speak to. All of my blobs are source code, so they are small-ish.

Probably true. Most of my trees are reasonably well distributed (they aren't that big). I think my largest is 900 files in the same directory.

I/use/java/programs/on/windows/and/much/of/my/source/is/in/that/format. :-) I don't really have issues with deep trees, and I have some pretty darn deep source code trees.

Don't see that.

Yes! Very much so. The packfiles are the first things to fragment, and what with all of the small files that Git creates, especially with frequent branch switching, and then the small object files that my build system creates, my drive is almost always completely fragmented.

Which reminds me, I need to defrag again...