> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST) > From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > cc: Alex Riesen <raa.lkml@xxxxxxxxx>, ae@xxxxxx, tsuna@xxxxxxxxxxxxx, > git@xxxxxxxxxxxxxxx, make-w32@xxxxxxx > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
