Re: [PATCH v4 0/1] receive-pack: optionally deny case clone refs

[Junio C Hamano <gitster@pobox.com>]

David Turner <dturner@twopensource.com> writes:

> This issue bit us again recently.
>
> In talking with some colleagues, I realized that the previous version
> of this patch, in addition to being potentially slow, was incomplete.
> Specifically, it didn't handle the case of refs/heads/case/one vs
> refs/heads/CASE/two; these are case clones even though they strcasecmp
> different.

Good catch to realize that two refs that share leading paths that
are the same except for cases are also problematic, but that makes
this feature even less about "case clones", doesn't it?

Also it somehow feels that the patch attempts to solve the issue at
a wrong level.  On a platform that cannot represent two refs like
these (e.g. trying to create "FOO" when "foo" already exists, or
trying to create "a/c" when "A/b" already exists---ending up with
"A/c" instead, which is not what the user wanted to create), would
it be more sensible to fail the ref creation without touching the
users of ref API such as receive-pack?  That way, you would also
catch other uses of refs that are not supported on your system,
e.g. "git branch a/c" when there already is a branch called "A/b",
no?

CC'ing those who are more active in the ref API area recently than I
am for their inputs.