From: "Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Johannes Sixt <j.sixt@viscovery.net>,
"Peter J. Weisberg" <pj@irregularexpressions.net>,
git@vger.kernel.org, Brandon Casey <drafnel@gmail.com>
Subject: Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'
Date: Thu, 22 Mar 2012 21:00:31 +0100 [thread overview]
Message-ID: <4F6B84DF.8040806@in.waw.pl> (raw)
In-Reply-To: <7viphwxyp1.fsf@alter.siamese.dyndns.org>
On 03/22/2012 07:44 PM, Junio C Hamano wrote:
> Jeff King<peff@peff.net> writes:
>
>> On Thu, Mar 22, 2012 at 09:57:23AM -0700, Junio C Hamano wrote:
>>
>>> Hrm, replacing unclear part with clarified text may make sense, but it
>>> would not help adding new text if the existing description is not clear
>>> enough.
>>>
>>> How about doing it like this?
>>>
>>> Case-insensitive filesystems like FAT and HFS+ have various strange
>>> behaviours, like reporting that a file "Makefile" already exists when
>>> the file that actually exists on them is "makefile". By setting this
>>> variable to `true`, Git employs logic to work around them.
I think that this paragraph is too judgemental. While case-insensitive
filesystems may be a pain, they are not "strange" to their users, but
rather natural, and don't require "working around".
> I guess we really need to make the description foolproof then.
>
> ... exists on them is "makefile". By setting this
> variable to `true`, Git employs logic to work around them.
> Setting this to `true` on a case insensitive filesystem does
> not make any sense, because it would not magically make your
> system to treat your filesystem case insensitively.
Even this updated text does not say _what_ happens when core.ignorecase
is set on a case-insensitive filesystem. Once that's cleared up, then
the corner case of core.ignorecase=true on case-sensitive fs can be tackled.
Maybe:
--- 8< ---
When set, case-insensitive comparisons will be used when internally
comparing file names.
The default is false, but when a new repository is created by
git-clone[1] or git-init[1], git will probe the filesystem and set it to
`true` if the filesystem is case-insensitive.
On case-insensitive filesystems like FAT, NTFS and HSF+, names that
differ only in capitalization, like "Makefile" and "makefile", refer to
the same file. While such filesystems usually preserve the
capitalization used during file creation, tools designed for such
filesystems will often modify capitalization when saving files and when
displaying filenames. Enabling core.ignorecase causes git to ignore
case-only differences in file names.
Enabling core.ignorecase on a case insensitive filesystem does
not make sense, because filenames with different capitalization will
still be treated as different by the filesystem.
--- >8 ---
[+cc Brandon Casey]
zByszek
next prev parent reply other threads:[~2012-03-22 20:00 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 22:50 [PATCH] Demonstrate failure of 'core.ignorecase = true' Peter J. Weisberg
2012-03-21 23:58 ` Junio C Hamano
2012-03-22 20:40 ` PJ Weisberg
2012-03-22 21:08 ` Junio C Hamano
2012-03-23 10:20 ` Thomas Rast
2012-03-23 17:47 ` Junio C Hamano
2012-03-23 18:48 ` Jeff King
2012-03-23 18:57 ` Jeff King
2012-03-22 6:49 ` Johannes Sixt
2012-03-22 11:25 ` Zbigniew Jędrzejewski-Szmek
2012-03-22 14:12 ` Jeff King
2012-03-22 16:57 ` Junio C Hamano
2012-03-22 17:37 ` Jeff King
2012-03-22 18:44 ` Junio C Hamano
2012-03-22 19:07 ` Jeff King
2012-03-22 20:33 ` Junio C Hamano
2012-03-22 20:00 ` Zbigniew Jędrzejewski-Szmek [this message]
2012-03-22 20:37 ` Junio C Hamano
2012-03-22 20:53 ` Zbigniew Jędrzejewski-Szmek
2012-03-22 20:55 ` PJ Weisberg
2012-03-22 21:09 ` Junio C Hamano
2012-03-22 23:00 ` Jeff King
2012-03-22 23:24 ` Junio C Hamano
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=4F6B84DF.8040806@in.waw.pl \
--to=zbyszek@in.waw.pl \
--cc=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=peff@peff.net \
--cc=pj@irregularexpressions.net \
/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;
as well as URLs for NNTP newsgroup(s).