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

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

[David Hagood]

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....)

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

[Johannes Schindelin]

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:

> 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....)

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

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

[Pete Harlan]

On 02/12/2010 05:14 AM, Johannes Schindelin wrote:
> 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:
> 
>> 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....)
> 
> 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.

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

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

[Claus Färber]

David Hagood <david.hagood@gmail.com> schrieb/wrote:
> 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,...

Mac OS X has the same problem.

Further, it does not preserve the Unicode normalisation form.

Claus

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

[Julian Phillips]

On 12 Feb 2010 19:19:00 +0100, gmane2010@cfaerber.name (Claus Färber)
wrote:
> David Hagood <david.hagood@gmail.com> schrieb/wrote:
>> 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,...
> 
> Mac OS X has the same problem.

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

> Further, it does not preserve the Unicode normalisation form.

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

-- 
Julian

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

[david.hagood]

> On 02/12/2010 05:14 AM, Johannes Schindelin wrote:
> I didn't read David's patch as anything other than floating an idea.
It also gets the issue out there and searchable.

> It sounds like this is a (3), which is doing pretty well for an idea
> about how to change Git :)
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.

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

[Daniel Barkalow]

On Fri, 12 Feb 2010, David Hagood wrote:

> 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....)

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*