Re: Cygwin: problem with renaming and case

From: Steffen Prohaska <prohaska@zib.de>
Date: Mar 22, 2008, 13:45 UTC
Message-ID: <alpine.OSX.1.00.0803221429390.7656@cougar>
In-Reply-To: <7vtzizmwd4.fsf@gitster.siamese.dyndns.org>

On Fri, 21 Mar 2008, Junio C Hamano wrote:

Show 12 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > My personal guess is that it's probably better to start teaching git about 
> > case-broken filesystem, even if we start it with some common special case 
> > rather than getting every case right from the beginning.
> 
> Hmm.  I have to say I am not very enthused by the prospect, as I agree
> with your reasoning in your earlier message why this has been lower
> priority ("sane people when forced to use case corrupting systems avoid
> problematic paths to make this a non-issue anyway").  My feeling is that
> this falls into the "when we are bored to death and have absolutely
> nothing better to do" category.

Sane people might be forced to modify paths in a problematic way more often than you think. A common error I see in practice is that a developer introduces a typo when adding a new header file on a "case-broken" filesystem. A typo that only introduces a different case in the filename and the matching #include statement is unrecognizable on a "case-broken" filesystem. The compiler will find the file regardless of the different case in the include statement. Only when the source is checked out on a case-sensitive filesystem the error is recognized and needs to be fixed. The lucky case is if the typo is in the #include statement. The problematic case is if the case of the filename wrong (violates the coding style of the project). In the latter case the file needs to be renamed to a path that only differs in case, which triggers the problem.

            Steffen