> Lee, could you improve your change in refs.c into a real patch, with a commit 
> message?
> (And please have a look at the indentation with TABs)
> A test case could be good, if time allows I can make a suggestion.

I will remove the refs.ignorecase flag and work on a test care or two,
it will have to wait a few days tho.

> (and everything else could and should go into another patch:
>  If we ever want Linux to ignore the case in refs,
>  to ease the cross-platform development with Windows.
>  Or if we allow Windows/Mac OS to handle case insensitive refs (by always 
> packing them)
>  to ease the co-working with e.g. Linux.
> )

I was actually planning on tying to add this to my changes if they
gained any traction. Why is another patch desirable?

> If the variable is not in 'core.' namespace, you should implement
> this check at the Porcelain level, allowing lower-level tools like
> update-ref as an escape hatch that let users bypass the restriction
> to be used to correct breakages; it would mean an unconditional "if
> !stricmp(), it is an error" in refs.c will not work well.
> I think it might be OK to have
>         core.allowCaseInsentitiveRefs = {yes|no|warn}
> which defaults to 'warn' (and 'yes' corresponds to 'allow', 'no'
> corresponds to 'error', in the previous suggestion), instead. If we
> wanted to prevent even lower-level tools like update-ref from
> bypassing the check, that is.

I also would not mind working on either of Junio's suggestions if one
is more desirable than what I already have.

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