On Wed, 2014-06-04 at 08:06 +0200, Johannes Sixt wrote: > > +receive.denyCaseCloneBranches:: > > + If set to true, git-receive-pack will deny a ref update that creates > > + a ref which is the same but for case as an existing ref. This is > > + useful when clients are on a case-insensitive filesystem, which > > + will cause errors when given refs which differ only in case. > > Shouldn't this better be named 'receive.denyCaseCloneRefs'? Yes. I'll fix that. > How about 'denyCaseInsensitiveRefs', 'denyIgnoreCaseRefs'? I don't love these, because it's not the case-insensitivity that's being denied but the duplication. > Is this entry really so important that it must be the first in the list of > receive.deny* list, which is not alphabetically sorted? I think the list should be sorted alphabetically, so that we don't have to worry about what is most important. <snip issues that I'll fix when I reroll> > BTW, on a case-insensitive file system, is there not a chance that 'git > rev-parse CaseClone' succeeds even though the ref is stored in > victim/.git/refs/heads/caseclone? Perhaps you should inspect the output of > 'git for-each-ref' for the expected result? (Mental note: At least a > case-preserving file system is required to run the test.) I'll look into that and fix if necessary. Thanks. <snip more issues that I'll fix when I reroll> -- 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