Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 22, 2012, 16:57 UTC
Message-ID: <7vbonozi8c.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120322141245.GB8803@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> I don't know. It says:
>
>   If true, this option enables various workarounds to enable git to work
>   better on filesystems that are not case sensitive, like FAT. For
>   example, if a directory listing finds "makefile" when git expects
>   "Makefile", git will assume it is really the same file, and continue
>   to remember it as "Makefile".
>
> which seems pretty clear to me that this is "let git work better on
> case-insensitive filesystems", not "make git magically case-insensitive
> on case sensitive filesystem".

Yes, it says what it needs to say quite clearly.

> But maybe we could add be more explicit,
> like:

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.

   The default is false, except that git-clone[1] and git-init[1] will
   probe the filesystem and set it to `true` as necessary when a new
   repository is created.