Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > 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. Thanks for a very sane comment. > Currently git handles references names case-sensitively and allows > multiple reference names that differ only in case. We do the same for in-tree paths, by the way. Ultimately, I think the sane thing to do is to appeal to the user's common sense. In a project where its participants may use, or in a project that is about, a platform where a case-folding filesystem is the default choice, the project would avoid in-tree paths that are different only in case and would not have xt_TCPMSS.c and xt_tcpmss.c at the same time. Even though Git allows you on such a platform to add case-conflicting pair of paths by using "update-index --cacheinfo", people would not do that, because it is not a useful thing to do. And Git by default does not forbid recording such pair of paths, as projects for whatever reason may want to use such pair of paths if they know its participants can deal with case sensitivity just fine. I think refnames have exactly the same issue. In theory, you could have "Master" and "master" branches, and nothing stops you from trying to do so, but in practice, if it is not useful for you and your project, and if it is equally fine to use some other name instead of "Master" for the purpose of you and your project, then there is no strong reason for doing so, unless you are trying to irritate users on case folding platforms. -- 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