On Tue, Nov 22, 2011 at 12:21 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > Is it obvious how references *should* be handled on case-insensitive > filesystems? It's certainly not obvious to me (has it been discussed > elsewhere?) I don't think it is a good idea to "fix" this one problem > without defining an overall policy. Indeed, I hadn't thought this through very well at all. My initial take was just that if I were on a case-insensitive file system, I don't get to have references that differ only in case. This is of course quite short-sighted in a distributed VCS. :-( > Currently git handles references names case-sensitively and allows > multiple reference names that differ only in case. If this behavior is > to be preserved on case-insensitive filesystems, then either loose > references must be stored differently (e.g., multiple references in the > same file) or ambiguous references need always to be packed. Moreover, > given a refname, we would need to be careful not to just try to open a > file with that name and assume that it is the correct reference; rather, > we would have to ask the filesystem for the name of the file in its > original case and make sure that it agrees with the case of the refname > that we seek. I wonder what the downside would be of always using packed refs on case-insenstive file systems. This would seem analogous to how git no longer uses symlinks. > By the way, this could have ramifications for the recently-added test > that top-level refnames should be in ALL_CAPS. > > 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. > > 2. Remain case-sensitive but prohibit refnames that differ only in case > *when running on a case-insensitive filesystem*. > > 3. Change the handling of refnames to be case-insensitive but > case-preserving. > > The above all assumes a case-insensitive filesystem that is > *case-preserving*. If we want to support filesystems that do not > preserve case, things get even more complicated. > > And if we want to pretend to support non-ASCII refnames, then the issue > of encodings is another nasty can of worms... These all seem like sub-optimal things to do if we can just always used packed refs. j. -- 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