> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
quoted text
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr, 
>     git@vger.kernel.org, make-w32@gnu.org
> 
> The problem is not so much opening, but determining if an existing file 
> and a file in the index have the same name.
> 
> For example, "README" in the index, but "readme" in the working directory, 
> will be handled as "deleted/untracked" by the current machinery.  IOW git 
> will not know that what it gets from readdir() as "readme" really is the 
> same file as "README" in the index.

That's because you think file names are simple strings and can be
compared by simple string comparison.  This naìve view is not true
even on POSIX systems: "foo/bar" and "/a/b/foo/bar" can be the same
file, as well as "/a/b/c/d" and "/x/y/z", given the right symlinks.
But for some reason that eludes me, people who are accustomed to POSIX
stop right there and in effect say "file names are strings, if we only
make them absolute and resolve links".  Instead, recognize that file
names are not strings (although they inherit some of the strings'
traits), and think in terms of "file-name comparison" abstraction;
then everything will fall in place just fine.

quoted text
> > > - no acceptable level of performance in filesystem and VFS (readdir,
> > >   stat, open and read/write are annoyingly slow)
> > 
> > With what libraries?  Native `stat' and `readdir' are quite fast. 
> > Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed 
> > painfully slow, but then you don't need to use it.
> 
> No, native.

Can you show a test case where this penalty is clearly visible?  I'm
curious to see the numbers.  TIA
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html