David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > On Thu, 2014-06-12 at 12:47 -0700, Junio C Hamano wrote: >> David Turner <dturner@xxxxxxxxxxxxxxxx> 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? > > 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 ;-) >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html