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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2014, 19:47 UTC
Message-ID: <xmqqa99h6hbh.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1402525838-31975-1-git-send-email-dturner@twitter.com>

David Turner <dturner@twopensource.com> writes:

Show 7 quoted lines

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