Re: [PATCH 0/7] Case-insensitive filesystem support, take 1

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 25, 2008, 21:04 UTC
Message-ID: <alpine.LFD.1.00.0803251347400.2775@woody.linux-foundation.org>
In-Reply-To: <20080325081409.GI25381@dpotapov.dyndns.org>

On Tue, 25 Mar 2008, Dmitry Potapov wrote:

Show 5 quoted lines

> 
> - 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