Jeff King [off-list ref] writes:
On Thu, Mar 22, 2012 at 09:57:23AM -0700, Junio C Hamano wrote:
quoted
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.
IMHO, it suffers from the same problem as the original, which is that it
does tells when to use core.ignorecase, but does not specify what
I wanted it to tell *what* happens when core.ignorecase is set. In other
words, I wanted the description to say that the logic employed is to work
around what case-insensitive filesystems do. Case sensitive filesystems
obviously do not do what case-insensitive ones do (like reporting a
"Makefile" exists when only "makefile" exists), so I hoped that it was
clear enough that the additional logic would not be suitable there.
happens when one sets core.ignorecase to true on a case-sensitive
filesystem. Maybe we should be more explicit about what _does_ happen in
that case (to be honest, I am not completely sure). Or just say that it
is not a supported use case.
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.
On Thu, Mar 22, 2012 at 11:44:42AM -0700, Junio C Hamano wrote:
I wanted it to tell *what* happens when core.ignorecase is set. In other
words, I wanted the description to say that the logic employed is to work
around what case-insensitive filesystems do. Case sensitive filesystems
obviously do not do what case-insensitive ones do (like reporting a
"Makefile" exists when only "makefile" exists), so I hoped that it was
clear enough that the additional logic would not be suitable there.
Ah. I see now why you made the change you did. But if I missed it,
perhaps it was too subtle (of course, I found the other one perfectly
adequate, so...).
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.
I'm OK with that (modulo s/insensitive/sensitive/ on the third line).
It may be overly explicit, but I would rather err on that side.
-Peff
On 03/22/2012 07:44 PM, Junio C Hamano wrote:
Jeff King[off-list ref] writes:
quoted
On Thu, Mar 22, 2012 at 09:57:23AM -0700, Junio C Hamano wrote:
quoted
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:
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.
[+cc Brandon Casey]
zByszek
On Thu, Mar 22, 2012 at 09:00:31PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
quoted hunk
Maybe:
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.
From his response, I guess Junio does not agree, but this is my favorite
of the texts proposed so far.
-Peff
PS If we do use it, it needs s/HSF/HFS/.