On Tue, 25 Mar 2008, Dmitry Potapov wrote: > > - merge different branches were two file names are only differ by case > will cause that the result branch has two file names that differ only > by case and one of them will be overwritten by the other and shown as > modified in the worktree by git status. Ok. So there's two issues here: - the git trees themselves had two different names This is not something I'm *ever* planning on changing. All my "case insensitive" patches were about the *working*tree*, not about core git data structures themselves. In other words: git itself is internally very much a case-sensitive program, and the index and the trees are case-sensitive and will remain so forever as far as I'm concerned. So when you do a tree-level merge of two trees that have two different names that are equivalent in case, git will create a result that has those two names. Because git itself is not case-insensitive. - HOWEVER - when checking things out, we should probably notice that we're now writing the two different files out and over-writing one of them, and fail at that stage. I don't know what a good failure behaviour would be, though. I'll have to think about it. IOW, all my case-insensitivity checking was very much designed to be about the working tree, not about git internal representations. Put another way, they should really only affect code that does "lstat()" to check whether a file exists or code that does "open()" to open/create a file. > - git status cares only about case-insensitivity only for files and not > for directories. Thus, if case of letters in a directory name is changed > then this directory will be shown as untracked. Ahh, yes. This is sad. It comes about because while we can look up whole names in the index case-insensitively, we have no equivalent way to look up individual path components, so that still uses the "index_name_pos()" model and then looking aroung the failure point to see if we hit a subdirectory. Remember: the index doesn't actually contain directories at all, just lists of files. This will not be trivial to fix. > - pattern specified in .gitignore are match as case-sensitive despite > core.ignorecase set to true. This should probably be fairly straightforward. All the logic here is in the function "excluded_1()" in dir.c - and largely it would be about changing that "strcmp()" into a "strcasecmp()" and using the FNM_CASEFOLD flag to fnmatch(). The only half-way subtle issues here are - do we really want to use strcasecmp() (which may match differently than our hashing matches!) or do we want to expand on our icase_cmp() or similar in hash-name.c (I think the latter is the right thing, but it requires a bit more work) - FNM_CASEFOLD has the same issue, but also adds the wrinkle of being a GNU-only extension. Which is sad, since most systems that have glibc would never need it in the first place. So then we get back to the whole issue of maybe having to reimplement 'fnmatch()', or at least a subset of it that git uses. So that last issue is conceptually simple and straightforward to fix, but fixing it right would almost certainly be a few hundred lines of code (fnmatch() in particular is nasty if you want to do all the cases, but perhaps just '*' is ok?). The first two issues are nontrivial. Linus -- 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
