Re: [PATCH v2 0/6] Extensions of core.ignorecase=true support

From: Robert Buck <buck.robert.j@gmail.com>
Date: Oct 3, 2010, 11:48 UTC
Message-ID: <AANLkTinZzM=HeT_J-tF5F9DBdvts3i+nboPkPy-uc8V5@mail.gmail.com>
In-Reply-To: <20101003043221.1960.73178.stgit@SlamDunk>

Referring back to my earlier comment to this patch series, which was proposed on August 17, while I tend to agree to the changes that help listing- operations, those changes that fold case concern me. Let me explain...

You may find there is a strong contingent of people that would approve of, and would want to use, case insensitivity for gitignore and ls, for example; but by tying the same single property (core.ignorecase) to the case folding behaviors some people would avoid the feature all together, which would be unfortunate, when they otherwise could benefit from at least one part of the new behavior.

There were several key things that went wrong in early git development, this and the eol support were two casualties. The eol support, as you recall, deprecated the old property in favor of a couple new superior ones. I would recommend that the same thing be done here, deprecate the old ignorecase property by introducing two better ones.

So I could we please separate the behaviors that change intent (folding) from the behaviors that merely alter how things are displayed (listing) by splitting this into two separate properties? For example,

core.casepreserving=true|false core.caseinsensitive=true|false

The former property would control folding, the latter property would apply to listing and pattern matching. Then people could opt out of the folding behaviors (add, import), while continuing to adopt listing and pattern matching (status, ls, ignore).

Again, deprecate core.ignorecase by making it default to {false,false} for the new properties if unspecified, which would also be the default if all three of the properties are unspecified. If ignorecase is specified to be true, then default to {false, true}, respectively.

Would this be possible?

On Sun, Oct 3, 2010 at 12:32 AM, Joshua Jensen <jjensen@workspacewhiz.com> wrote:

Show 63 quoted lines

> The second version of this patch series fixes the problematic case
> insensitive fnmatch call in patch 1 that relied on an apparently GNU-only
> extension.  Instead, the pattern and string are lowercased into
> temporary buffers, and the standard fnmatch is called without relying
> on the GNU extension.
>
> Patches 2-6 received no modifications.
>
> The original cover for the patch series follows as posted by Johannes Sixt:
>
> The following patch series extends the core.ignorecase=true support to
> handle case insensitive comparisons for the .gitignore file, git status,
> and git ls-files.  git add and git fast-import will fold the case of the
> file being added, matching that of an already added directory entry.  Case
> folding is also applied to git fast-import for renames, copies, and deletes.
>
> The most notable benefit, IMO, is that the case of directories in the
> worktree does not matter if, and only if, the directory exists already in
> the index with some different case variant.  This helps applications on
> Windows that change the case even of directories in unpredictable ways.
> Joshua mentioned Perforce as the primary example.
>
> Concerning the implementation, Joshua explained when he initially submitted
> the series to the msysgit mailing list:
>
>  git status and add both use an update made to name-hash.c where
>  directories, specifically names with a trailing slash, can be looked up
>  in a case insensitive manner. After trying a myriad of solutions, this
>  seemed to be the cleanest. Does anyone see a problem with embedding the
>  directory names in the same hash as the file names? I couldn't find one,
>  especially since I append a slash to each directory name.
>
>  The git add path case folding functionality is a somewhat radical
>  departure from what Git does now. It is described in detail in patch 5.
>  Does anyone have any concerns?
>
> I support the idea of this patch, and I can confirm that it works: I've
> used this series in production both with core.ignorecase set to true and
> to false, and in the former case, with directories and files with case
> different from the index.
>
> Joshua Jensen (6):
>      Add string comparison functions that respect the ignore_case variable.
>      Case insensitivity support for .gitignore via core.ignorecase
>      Add case insensitivity support for directories when using git status
>      Add case insensitivity support when using git ls-files
>      Support case folding for git add when core.ignorecase=true
>      Support case folding in git fast-import when core.ignorecase=true
>
>
>  dir.c         |  152 ++++++++++++++++++++++++++++++++++++++++++++++++++-------
>  dir.h         |    4 ++
>  fast-import.c |    7 ++-
>  name-hash.c   |   72 +++++++++++++++++++++++++++
>  read-cache.c  |   23 +++++++++
>  5 files changed, 235 insertions(+), 23 deletions(-)
>
>
> --
> 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
>