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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html