Re: Switching from CVS to GIT
- From
Steffen Prohaska <prohaska@zib.de>
- Date
- Oct 16, 2007, 07:14 UTC
- Message-ID
- <2EA3BEC9-5B13-44D3-B190-CA77499F642C@zib.de>
- In-Reply-To
- <471448D0.6080200@op5.se>
On Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:
Show 25 quoted lines
> 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