Re: Branch Name Case Sensitivity

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 3, 2014, 17:51 UTC
Message-ID: <xmqqsiqzrwzr.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAJHY66EP539ZsLJcmHcnRQcOqcLqXK-M45wME9DkKkqmumg8fA@mail.gmail.com>

Lee Hopkins <leerhop@gmail.com> writes:

Show 12 quoted lines

> I went ahead and took a stab at a solution. My solution is more
> aggressive than a warning, I actually prevent the creation of
> ambiguous refs. My changes are also in refs.c, which may not be
> appropriate, but it seemed like the natural place.
>
> I have never contributed to Git (in fact this is my first dive into
> the source) and my C is a bit rusty, so bear with me, this is just a
> suggestion:
>
> ---
>  refs.c |   31 ++++++++++++++++++++++++-------
>  1 files changed, 24 insertions(+), 7 deletions(-)

Starting something like this from forbidding is likely to turn out to be a very bad idea that can break existing repositories.

A new configuration

	refs.caseInsensitive = {warn|error|allow}

that defaults to "warn" and the user can choose to set to "error" to forbid, would be more palatable, I would say.

If the variable is not in 'core.' namespace, you should implement this check at the Porcelain level, allowing lower-level tools like update-ref as an escape hatch that let users bypass the restriction to be used to correct breakages; it would mean an unconditional "if !stricmp(), it is an error" in refs.c will not work well.

I think it might be OK to have

	core.allowCaseInsentitiveRefs = {yes|no|warn}

which defaults to 'warn' (and 'yes' corresponds to 'allow', 'no' corresponds to 'error', in the previous suggestion), instead. If we wanted to prevent even lower-level tools like update-ref from bypassing the check, that is.