Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Dec 25, 2010, 02:20 UTC
- Message-ID
- <AANLkTi=tyEPWMxo2OGbgnCAE938aYzSvaWr7WyZFj3nF@mail.gmail.com>
- In-Reply-To
- <4D14CFF2.9050705@workspacewhiz.com>
On Fri, Dec 24, 2010 at 11:53 PM, Joshua Jensen <jjensen@workspacewhiz.com> wrote:
Show 7 quoted lines
> 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.
Hmm.. what you describe sounds like never_interesting optimization in tree_entry_interesting(). By the way do you still remember the parts that it walk sequentially after ce_path_match() is matched?
Show 7 quoted lines
> 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.
Resorting the cache is quite risky. Many parts of git depend on the cache being sorted as it is now. Also if you go this way, then you will also need to resort tree objects (git-log walks them directly).
-- Duy