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"? > 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? This might be somewhat complicated because we could be starting from a repo which already has case conflicts. What should we do about that? I think this is even possible on a case-insensitive filesystem with packed-refs, although I have not checked. The simplest idea is probably to pretend that the first conflicting refname component we find is the one true one, and reject new refs containing versions which are case conflicting with this one until the user cleans up their repo. 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? If so, I think it is possible, and if I don't hear anything back from the other ref folks, I'll see if I have time to implement it. -- 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