> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST) > From: Johannes Schindelin <[EMAIL PROTECTED]> > cc: Alex Riesen <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], [email protected] > > 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. > > > - 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 _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
