Git under Windows should warn or fail on entities differning only in case

I work in a mixed Windows and Linux development team where we have an embedded project that we are storing in GIT. However, we got bit by what is arguably a bug in Windows, but...

If you have 2 entities in a directory which have names differing only in case, e.g. "foo" and "FOO", under a REAL operating system with case sensitive file system semantics, this is no problem. However, under Windows and their wonderful "Case preserving but case insensitive" semantics, "FOO" and "foo" would be the same file, so when you pull/checkout/clone a repo with this condition, Windows will overwrite one file, then Git will always see a "change" because one file or the other won't be "right".

I would suggest that git should check for this case, and generate a big warning about it when it happens. (Yes, it sucks burdening Git with Windows' problems....)

Hi,

Disclaimer: I am not uninterested in the subject you talk about, but my 
reply could come over as harsh, due to lack of time. If you are likely to 
be annoyed by direct criticism, delete this mail and do not reply. Thank 
you very much.

On Fri, 12 Feb 2010, David Hagood wrote:

Git is burdened with Windows' problems already. That does not suck. What sucks is that you only suggest that Git should check the case, in effect asking the few Git for Windows contributors to do it, instead of just going ahead and scratching your own itch.

Ciao, Dscho

On 02/12/2010 05:14 AM, Johannes Schindelin wrote:

I didn't read David's patch as anything other than floating an idea.

Posting a wish item to the list without a patch seems useful to me:

1. Someone might be able to explain why the wished-for item is a bad
idea, or why it's unfeasible to implement.

2. Someone might have a flash of insight for how to implement the idea
in a few lines of code and post the patch, improving Git.

3. Someone might say, "Good idea, go ahead and make the change," and the
person with the itch now knows that the idea will be accepted.

It sounds like this is a (3), which is doing pretty well for an idea about how to change Git :)

--Pete

It also gets the issue out there and searchable.

If only I weren't working on a 15 man-year project that has a 4 month delivery time, trying to keep all my sub-ordinates unblocked.

David Hagood <david.hagood@gmail.com> schrieb/wrote:

Mac OS X has the same problem.

Further, it does not preserve the Unicode normalisation form.

Claus

On 12 Feb 2010 19:19:00 +0100, gmane2010@cfaerber.name (Claus Färber) wrote:

Only by default. You can choose to use a case sensitive filesystem if you wish.

Unfortunately you can't choose to turn this off. :(

On Fri, 12 Feb 2010, David Hagood wrote:

There are several possible paths here (at least one of which is something that's been discussed and agreed to in principle, but nobody is interested in implementing):

 - Git for Windows could detect that your project isn't going to fit in 
   the Windows filesystem, because it knows the rules for filename 
   comparison on that filesystem and there are overlaps.

 - Git in general could detect that the filesystem thinks multiple names 
   your project uses are for the same file, because when it started "FOO" 
   didn't exist, now it does, and it's got the same stat info as some file 
   that git wrote in this interval.

 - Git in general could see that your project has declared that it's 
   partially developed on a system that conflates filenames in certain 
   patterns and/or treats certain filenames as being octet-wise different 
   filenames, and warn you, regardless of where you're running git, if you 
   create files that will be a problem, either for you or for other 
   people.

I think you'd only really benefit from the third of these; with either of the first two, the Windows users will find out in a clear way that they've got problems, which is nice, but the Linux users won't get the instant feedback necessary to keep them from causing the problems, and the Windows users can't do much about the problems at that point, either.

Git does support putting whitespace policy rules in .gitattributes and warning about violations of them in some operations. It would not be unreasonable for git to support filename policy rules similarly, which could be handy not only for Windows users, but for people who people who want to refer to filenames over the telephone ("No, xt underscore *lowercase* connmark dot c") or can only type some characters (imagine how much fun it would be for a project to have subdirectories for different economic zones, each named with the currency symbol for that zone; the computer has no problem with them, but each developer has a keyboard that only has a key for a different one or two of them).

	-Daniel
*This .sig left intentionally blank*