git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 5/5] attr.c: respect core.ignorecase when matching attribute patterns

From
Junio C Hamano <gitster@pobox.com>
Date
Oct 11, 2011, 00:00 UTC
Message-ID
<7vmxd8ieid.fsf@alter.siamese.dyndns.org>
In-Reply-To
<4E91BAC8.9060606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 13 quoted lines
> On 10/06/2011 08:22 PM, Brandon Casey wrote:
>> The last set of tests is performed only on a case-insensitive filesystem.
>> Those tests make sure that git handles the case where the .gitignore file
>> resides in a subdirectory and the user supplies a path that does not match
>> the case in the filesystem.  In that case^H^H^H^Hsituation, part of the
>> path supplied by the user is effectively interpreted case-insensitively,
>> and part of it is dependent on the setting of core.ignorecase.  git should
>> only match the portion of the path below the directory holding the
>> .gitignore file according to the setting of core.ignorecase.
>
> ... It is hard to imagine that
> anybody *wants* part of a single filename to be matched
> case-insensitively and another part to be matched case-sensitively.

That is not necessarily coming from the user's wish. When a command that takes a pathspec from the user is run from a subdirectory, almost always the output from $(git rev-parse --show-prefix) is prefixed to them. This value is read from the filesystem, and unless on a system whose readdir() may lie to us, we do not _have_ to ignore the case of this part of the substring of a resulting pathspec element to get a successful match, even though we _do_ want to match the user-supplied part case insensitively if/when the user says he wants us to with core.ignorecase.

Having said that, it may not hurt in practice if we matched the prefix part case insensitvely, because prefix=foobar/ obtained on a filesystem where core.ignorecase is true would mean there won't be FooBar/ and other case-permuted names on the filesystem at the same time.

But of course I may be missing something...
Previous: Junio C Hamano
Message 13 of 13 in “attr.c: avoid inappropriate access to strbuf "buf" member”
  1. 1/5 attr.c: avoid inappropriate access to strbuf "buf" memberBrandon Casey, Oct 6, 2011
  2. 2/5 cleanup: use internal memory allocation wrapper functions everywhereBrandon Casey, Oct 6, 2011
  3. 3/5 builtin/mv.c: plug miniscule memory leakBrandon Casey, Oct 6, 2011
  4. 4/5 attr: read core.attributesfile from git_default_core_configBrandon Casey, Oct 6, 2011
  5. 5/5 attr.c: respect core.ignorecase when matching attribute patternsBrandon Casey, Oct 6, 2011
  6. Michael HaggertyOct 9, 2011
  7. Brandon CaseyOct 10, 2011
  8. Michael HaggertyOct 11, 2011
  9. attr.c: respect core.ignorecase when matching attribute patternsBrandon Casey, Oct 11, 2011
  10. Junio C HamanoOct 11, 2011
  11. Brandon CaseyOct 12, 2011
  12. Junio C HamanoOct 12, 2011
  13. Junio C HamanoOct 11, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.