On Fri, 21 Mar 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
--
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
