On Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:

quoted text
> Eli Zaretskii wrote:
>>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
>>> From: Daniel Barkalow <barkalow@iabervon.org>
>>> cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de,  
>>> ae@op5.se,     tsuna@lrde.epita.fr, git@vger.kernel.org, make- 
>>> w32@gnu.org
>>>
>>> I believe the hassle is that readdir doesn't necessarily report a  
>>> README in a directory which is supposed to have a README, when it  
>>> has a readme instead.
>> 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
>
> and there's really no easy way out of this one, since users on a case-
> sensitive filesystem might be involved in this project too, so it
> could be an intentional rename, but we don't know for sure. Just
> clobbering the in-git file is wrong, but overwriting a file on disk
> is wrong too. git tries hard to not ever lose any data for the user.

Maybe we need a configuration similar to core.autocrlf (which controls
newline conversion) to control filename comparison and normalization?

Most obviously for the case (in-)sensitivity on Windows, but I also
remember the unicode normalization happening on Mac's HFS filesystem
that caused trouble in the past.

	Steffen
-
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