Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. -- 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