Hi,

[by explicit request culling make-w32 from the Cc list]

On Tue, 16 Oct 2007, Eli Zaretskii wrote:

quoted text
> > Date: Tue, 16 Oct 2007 07:14:56 +0200
> > From: Andreas Ericsson <ae@op5.se>
> > CC: Daniel Barkalow <barkalow@iabervon.org>,  raa.lkml@gmail.com, 
> >  Johannes.Schindelin@gmx.de,  tsuna@lrde.epita.fr,  git@vger.kernel.org, 
> >  make-w32@gnu.org
> > 
> > > Sorry I'm asking potentially stupid questions out of ignorance: why
> > > would you want readdir to return `README' when you have `readme'?
> > > 
> > 
> > Because it might have been checked in as README, and since git is case
> > sensitive that is what it'll think should be there when it reads the
> > directories. If it's not, users get to see
> > 
> > 	removed: README
> > 	untracked: readme
> 
> This is a non-issue, then: Windows filesystems are case-preserving, so 
> if `README' became `readme', someone deliberately renamed it, in which 
> case it's okay for git to react as above.

No, it is not.  On FAT filesystems, for example, I experienced Windows 
happily naming a file "head" which was created under then name "HEAD".

This is the single reason why I cannot have non-bare repositories on a USB 
stick.

quoted text
> > could be an intentional rename, but we don't know for sure.
> 
> It _must_ have been an intentional rename.

No.  It can also be the output of a program which deletes the file first, 
and then (since the filesystem is so "conveniently" case insensitive) 
creates it again, with a lowercase filename.

And don't you tell me that there are no such programs.  I have to use 
them, and they are closed source.

Sigh.

quoted text
> > To be honest though, there are so many places which do the 
> > readdir+stat that I don't think it'd be worth factoring it out
> 
> Something for Windows users to decide, I guess.  It's not hard to 
> refactor this, it just needs a motivated volunteer.

You?

quoted text
> > I *think* (correct me if I'm wrong) that git is still faster
> > than a whole bunch of other scm's on windows, but to one who's used to
> > its performance on Linux that waiting several seconds to scan 10k files
> > just feels wrong.
> 
> Unless that 10K is a typo and you really meant 100K, I don't think 10K
> files should take several seconds to scan on Windows.  I just tried
> "find -print" on a directory with 32K files in 4K subdirectories, and
> it took 8 sec elapsed with a hot cache.  So 10K files should take at
> most 2 seconds, even without optimizing file traversal code.  Doing
> the same with native Windows system calls ("dir /s") brings that down
> to 4 seconds for 32K files.

On Linux, I would have hit Control-C already.  Such an operation typically 
takes less than 0.1 seconds.

quoted text
> On the other hand, what packages have 100K files?

Mozilla, KDE, OpenOffice.org, X.org, ....

Ciao,
Dscho

-
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