Re: First cut at git port to Cygwin

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 7, 2005, 15:34 UTC
Message-ID: <Pine.LNX.4.64.0510070828270.31407@g5.osdl.org>
In-Reply-To: <81b0412b0510070544v3e7cf0b4n521db8ff7e4e335a@mail.gmail.com>

On Fri, 7 Oct 2005, Alex Riesen wrote:

Show 8 quoted lines

>
> it suddenly get worse: now I'm stuck on git-pull.
> 
> git-merge-index (called at some point by git-pull) maps the index in, and starts
> git-merge-one-file for each (or the given) entry in the index.
> git-merge-one-file
> calls git-update-index, which wants to update the index. Which doesn't work,
> because it's locked by that piece of s$%^.

NOTE! git doesn't use mmap() because it _needs_ to use mmap(), but because it was simple to do that way, and it's a total idiosyncracy of mine that I often try to mmap the data. I often also tend to do my own allocators instead of using malloc() (see my "sparse" project in case you're interested in other idiosyncracies of mine - macros to do list traversal etc).

The fact is, "mmap()" isn't really any better than "read()": it has some advantages wrt memory management for the kernel, which is probably one big reason why I do it, but quite frankly, if you were to change every single mmap() to be a "map_file()" instead, and made it optional whether it used mmap() or "malloc + read()", I personally don't think it would be horrible.

And it might make things much simpler for portability. The "use mmap" approach is very much a unixism, particularly the way unix people do it (mmap followed by close, making the file descriptor "go away"). Sure, other OS's have mmap too, but I think on them it tends to be less commonly used.

			Linus