On Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:
Eli Zaretskii wrote:
Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
From: Daniel Barkalow <barkalow@xxxxxxxxxxxx>
cc: Alex Riesen <raa.lkml@xxxxxxxxx>, Johannes.Schindelin@xxxxxx,
ae@xxxxxx, tsuna@xxxxxxxxxxxxx, git@xxxxxxxxxxxxxxx, make-
w32@xxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
