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

Reply via email to