From: Steffen Prohaska <prohaska@zib.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Avery Pennarun <apenwarr@gmail.com>,
Frank <streamlake@tiscali.it>,
git@vger.kernel.org
Subject: Re: Cygwin: problem with renaming and case
Date: Sat, 22 Mar 2008 14:45:52 +0100 (CET) [thread overview]
Message-ID: <alpine.OSX.1.00.0803221429390.7656@cougar> (raw)
In-Reply-To: <7vtzizmwd4.fsf@gitster.siamese.dyndns.org>
On Fri, 21 Mar 2008, Junio C Hamano wrote:
> 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
next prev parent reply other threads:[~2008-03-22 13:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 16:07 Cygwin: problem with renaming and case Frank
2008-03-21 17:46 ` Linus Torvalds
2008-03-21 17:57 ` Avery Pennarun
2008-03-21 18:09 ` Linus Torvalds
2008-03-22 0:32 ` Junio C Hamano
2008-03-22 13:45 ` Steffen Prohaska [this message]
2008-03-21 18:57 ` Dmitry Potapov
2008-03-21 19:37 ` streamlake
2008-03-21 19:54 ` Brian Dessent
2008-03-22 19:58 ` Nagy Balázs
2008-03-22 20:18 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.OSX.1.00.0803221429390.7656@cougar \
--to=prohaska@zib.de \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=streamlake@tiscali.it \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox