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.
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.
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
