All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>,
	"Johannes Sixt" <j.sixt@viscovery.net>,
	"Peter J. Weisberg" <pj@irregularexpressions.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] Demonstrate failure of 'core.ignorecase = true'
Date: Thu, 22 Mar 2012 11:44:42 -0700	[thread overview]
Message-ID: <7viphwxyp1.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120322173701.GA11928@sigill.intra.peff.net> (Jeff King's message of "Thu, 22 Mar 2012 13:37:01 -0400")

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.
>> 
>>    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.

  reply	other threads:[~2012-03-22 18:44 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 [this message]
2012-03-22 19:07             ` Jeff King
2012-03-22 20:33               ` Junio C Hamano
2012-03-22 20:00             ` Zbigniew Jędrzejewski-Szmek
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=7viphwxyp1.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    --cc=peff@peff.net \
    --cc=pj@irregularexpressions.net \
    --cc=zbyszek@in.waw.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.