I found that mmap() works on cygwin, but needs a patch.
On Cygwin, rename() fails if target file has active mmap().
The patch below adds  munmap() before rename().

If you excuse me for posting not in git-generated format
(I did not yet completely make git working on my cygwin).
I'm adding the copy as attachment, I'm afraid the mailer
may interfere with spaces ?

Yakov Lerner

Makefile     |    5 +++++
cache.h      |    1 +
index.c      |    3 +++
read-cache.c |   14 ++++++++++++++

--- Makefile.000 2006-05-07 22:32:04.000000000 +0300
+++ Makefile 2006-05-07 22:30:38.000000000 +0300
@@ -46,6 +46,9 @@
#
# Define NO_MMAP if you want to avoid mmap.
#
+# Define MUMNAP_BEFORE_RENAME if munmap() on target file is required
+# before rename().
+#
# Define WITH_OWN_SUBPROCESS_PY if you want to use with python 2.3.
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
@@ -270,6 +273,8 @@
# NO_MMAP =3D YesPlease
NO_IPV6 =3D YesPlease
X =3D .exe
+ MUMNAP_BEFORE_RENAME =3D YesPlease
+ NO_SOCKADDR_STORAGE =3D YesPlease
endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV =3D YesPlease
--- cache.h.000 2006-05-02 11:35:50.000000000 +0300
+++ cache.h 2006-05-02 11:33:34.000000000 +0300
@@ -140,6 +140,7 @@

/* Initialize and use the cache information */
extern int read_cache(void);
+extern void unmap_cache(void);
extern int write_cache(int newfd, struct cache_entry **cache, int entries);
extern int cache_name_pos(const char *name, int namelen);
#define ADD_CACHE_OK_TO_ADD 1 /* Ok to add */
--- read-cache.c.000 2006-05-07 22:33:42.000000000 +0300
+++ read-cache.c 2006-05-02 11:32:56.000000000 +0300
@@ -513,6 +513,9 @@
return 0;
}

+static void *mapaddr =3D MAP_FAILED;
+static unsigned long mapsize;
+
int read_cache(void)
{
int fd, i;
@@ -541,6 +544,8 @@
errno =3D EINVAL;
if (size >=3D sizeof(struct cache_header) + 20)
map =3D mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
+ mapaddr =3D map;
+ mapsize =3D size;
}
close(fd);
if (map =3D=3D ...
[ message continues ]

This is interesting in three counts.

 - I from time to time test Cygwin version on my day-job machine
   (W2K) and my wife's machine (XP); on both machines I usually
   have less than two weeks old Cygwin installation, and I have
   not seen the breakage.  I wonder how reproducible this is.
   Also previously people reported mmap() works for some and
   fake mmap is needed for others.  Would this patch make things
   work for everybody?

 - The part you patched is commit_index_file().  This typically
   is called just before program exit, but some callers, like
   apply.c, may want to still look at the index after calling
   it, fully aware that the changes after commit_index will not
   be written out.  Although I haven't traced the codepath fully
   in apply.c yet, unmapping would break the access to the index
   (i.e. active_cache[]).  Does apply still work with your
   patch?

 - As long as you can clear the second point, I do not see a
   particular reason to make this an option; we should be able
   to do so everywhere.

-

[ message continues ]

I am checking this. I am trying different options and different
scenarios.

Yakov
-

[ message continues ]

You are right. Apply did not work when I gave it more than one patchfile on
commandline (and --index option). I fixed this by zeroing active_nr and fre=
eing
active_cache in unmap_cache(). Then I got infinite loop in
remove_lock_file (after multiple calls to hold_index_file_for_update
with same cf, cache_file_list points to cf and cf->next points to
cf creating infinite loop.) The fix in index.c is easy.

The patch below works for me. However, it changes internal
working of apply.c in the scenario 'git-apply --index patch1 patch2 ...'.

(1) With the patch below, apply.c repeats mmap() on index after every patch
argument (because index gets unmapped after every patchfile argument).

(2) Current apply.c does single mmap() at the beginning. It modfies index
on disk and cache in memory and it does not repeat mmap. This mmap
is to original (now deleted) index, if i understand correctly (the
no-name inode).

But (2) this does not work in cygwin. The end results of (1) and
(2) are the same, I think. (2) looks to me bit faster (I didn't do
measurements).

It's up to you whether to make it under #ifdef MUNMAP_BEFORE_RENAME
of not. The changes are now bigger that in original patch.

The fix to index.c prevents circular list. I got infinite loop in
cache_file_list
every time I tried more than 1 patch on commandline of git-apply. I tried
other solution with the function below, but what I put in the atached patch
is shorter than the alternative below.

Yakov

P.S. I am attaching not inlining bacause
gmail totally removes leading tabs from inline text.

P.P.S.
Alternate fix for index.c:

static void clean_cache_file_list(struct cache_file *cf)
{
        struct cache_file *ppcf =3D &cache_file_list;
        cf->lockfile[0] =3D 0;
        while( *ppcf ) {
            if(*ppcf =3D=3D cf ) {
                *ppcf =3D cf->next;
            } else
                ppcf =3D &(cf->next);
        }
}
-         cf->lockfile[0] =3D 0;
+        clean_cache_file_list(cf);
-         ...
[ message continues ]

I suspect that essentially means you are forcing the cache to be
read again after writing it out, in which case I think you are
better off using NO_MMAP as Alex suggests.

-

[ message continues ]