Re: Possible bug with branch names and case sensitivity
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 22, 2011, 18:01 UTC
- Message-ID
- <7vsjlgdoju.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4ECB315F.4080701@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> 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.