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
Michael Haggerty <mhagger@alum.mit.edu>
Date
Oct 9, 2011, 15:16 UTC
Message-ID
<4E91BAC8.9060606@alum.mit.edu>
In-Reply-To
<U4wiHVyDLLG1PhI-8iY3YhHT7CEcTMEfg9MCDSaeuwAkg0N1a5wRE5NXaKAVQx8kpEYt75REVpRavoc-HiKe6rLk2AUepzHWptkevo08MRbGyWxqBHT_rySLemcbi66NKLRXwFGtaRQ@cipher.nrlssc.navy.mil>
On 10/06/2011 08:22 PM, Brandon Casey wrote:
Show 8 quoted lines
> 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.

Isn't this a rather perverse scenario? 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. ISTM that a person who is using a case-insensitive filesystem and has core-ignorecase=false is (1) a glutton for punishment and (2) probably very careful to make sure that the case of all pathnames is correct. So such a person is not likely to benefit from this schizophrenic behavior.

> [...]  If git instead built the attr
> stack by scanning the repository, then the paths in the origin field would
> not necessarily match the paths supplied by the user.  If someone makes a
> change like that in the future, these tests will notice.

Your decision to treat path names as partly case-insensitive will make this kind of improvement considerably more complicated.

Therefore, weighing the negligible benefit of declaring this schizophrenic behavior against the potential big pain of remaining backwards-compatible with this behavior, I suggest that we either (1) declare that when core.ignorecase=false then the *whole* filenames (including the path leading up to the .gitignore file) must match case-sensitively, or (2) declare the behavior in this situation to be undefined so that nobody thinks they should depend on it.

But given that I'm a potential implementer but not a potential Windows user, perhaps my judgment is biased...

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Brandon CaseyNext: Brandon Casey
Message 6 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.