Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)

From: Joshua Jensen <jjensen@workspacewhiz.com>
Date: Dec 24, 2010, 16:53 UTC
Message-ID: <4D14CFF2.9050705@workspacewhiz.com>
In-Reply-To: <AANLkTikaBfVw-4eD9qeGSdM5xKxq-gJ-3oAe4B2qt4od@mail.gmail.com>

----- Original Message -----
From: Nguyen Thai Ngoc Duy
Date: 12/23/2010 6:39 PM

Show 5 quoted lines

> If you have not known already, path in "git log ref -- path" must be
> case sensitive. Solving that is not hard: ce_path_match() and
> tree_entry_interesting() are the ones that do path matching. Those
> functions are nearly replaced in this series. I'll add
> case-insensitive support to them, so you can worry about other places.

As I recall (I'd have to examine other unsubmitted case insensitivity patches), merely adding case insensitivity support to ce_path_match() is not enough. The cache is stored alphabetically in a case sensitive fashion. That means filenames starting with 'A' are stored in a completely different place than filenames starting with 'a'. Certain parts of the code call ce_path_match() and then walk the cache sequentially for possible matches. It aborts long before hitting the 'a' filename.

I have a patch that appears to resolve most of these issues. For core.ignorecase=true, when the cache is read, it is re-sorted alphabetically in a case insensitive manner. ce_path_match() still needs fixes, but the rest were covered by the case insensitive cache. 'A' and 'a' are not interleaved, and the combination of sequential and binary(?) searches Git uses are successful. Finally, when the cache is written, I re-sort the cache in a case insensitive fashion.

Hmmm... I think this was also needed for the *_name_compare() functions, too.

Anyway, just something to consider.

Josh