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

David Turner [off-list ref] writes:

On Thu, 2014-06-12 at 12:47 -0700, Junio C Hamano wrote:

quoted

David Turner [off-list ref] writes:

quoted

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?

I agree: word "clone" is less good now.  Maybe "case conflicts"?

Sounds better but I'd like to hear from the ref people first, as
they have thought about it longer than I have ;-)

quoted

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?

So we would change is_refname_available?  And to do this, we would
change the ref_dir functions to take case into account?
...
In other
words, if the user has A/b and a/c already, and we find A/b first, then
we reject a/d but allow A/d.   This is arbitrary, but workable.  We
could warn about this situation when we load up the refs, too.  

Does this match what you are suggesting? 

Yes.  But again, I'd like to hear from the ref people first.  They
may have better ideas.