From: Joshua Jensen <jjensen@workspacewhiz.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
Date: Fri, 24 Dec 2010 09:53:06 -0700 [thread overview]
Message-ID: <4D14CFF2.9050705@workspacewhiz.com> (raw)
In-Reply-To: <AANLkTikaBfVw-4eD9qeGSdM5xKxq-gJ-3oAe4B2qt4od@mail.gmail.com>
----- Original Message -----
From: Nguyen Thai Ngoc Duy
Date: 12/23/2010 6:39 PM
> 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
next prev parent reply other threads:[~2010-12-24 16:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 1:59 What's cooking in git.git (Dec 2010, #06; Tue, 21) Junio C Hamano
2010-12-22 11:05 ` Thiago Farina
2010-12-22 11:39 ` Andreas Ericsson
2010-12-22 20:48 ` Junio C Hamano
2010-12-22 23:08 ` Thiago Farina
2010-12-23 15:52 ` Heiko Voigt
2010-12-23 16:32 ` Nguyen Thai Ngoc Duy
2010-12-23 17:17 ` Junio C Hamano
2010-12-23 23:35 ` Joshua Jensen
2010-12-24 1:39 ` Nguyen Thai Ngoc Duy
2010-12-24 16:53 ` Joshua Jensen [this message]
2010-12-25 2:20 ` Nguyen Thai Ngoc Duy
2010-12-24 19:23 ` Junio C Hamano
2010-12-24 20:02 ` Joshua Jensen
2010-12-24 1:33 ` Nguyen Thai Ngoc Duy
2010-12-26 10:46 ` Thomas Rast
2010-12-26 19:28 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D14CFF2.9050705@workspacewhiz.com \
--to=jjensen@workspacewhiz.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).