Re: Possible bug with branch names and case sensitivity

Michael Haggerty [off-list ref] writes:

If we want to consider bending git's behavior, there are a number of
ways we could go:

1. Remain case-sensitive but prohibit refnames that differ only in case.

I do not see a strong enough reason to be that draconian.

2. Remain case-sensitive but prohibit refnames that differ only in case
*when running on a case-insensitive filesystem*.

If you make it conditional, it should be per-project, not per-repository.
You may be participating in a cross platform project and you may happen to
be on the case-sensitive system, but absense of such a check for you may
end up hurting other participants who work on a case-insensitive one.

3. Change the handling of refnames to be case-insensitive but
case-preserving.

I do not see it is worth the effort. If you were to expend much effort
then I could see in the longer term (now I am talking about Git 2.0 in
this paragraph) one solution is to remove on-filesystem $GIT_DIR/refs/
hierarchy, put it in a trivial database of some sort, keyed with case
sensitive strings.

The transfer of refs over the wire will stay case sensitive so such a
change would be purely local to the repository, so transition would only
matter if you network mount a new style repository and attempt to use with
older version of Git.

If you go that route, we still would need to think about how to deal with
the $GIT_DIR/logs/ hierarchy, though.