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

Re: [PATCH v4] attr.c: respect core.ignorecase when matching attribute patterns

From
Brandon Casey <casey@nrlssc.navy.mil>
Date
Oct 12, 2011, 20:18 UTC
Message-ID
<y0zSE7mQNTqQ3B_hRG_UvK2pQCTYIP8jr_bGkjb8qdCqyfJ544ZQhQCmwkL-_MxlparVZWmDgqL7VO68y3trgjciKw2QRAK_j7KNVcXXJW0@cipher.nrlssc.navy.mil>
In-Reply-To
<7v8vorh3kg.fsf@alter.siamese.dyndns.org>
On 10/11/2011 11:54 AM, Junio C Hamano wrote:
Show 18 quoted lines
> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> ...  Currently, git builds the attr stack
>> based on the path supplied by the user, so we don't have to do anything
>> special (like use strcmp_icase) to handle the parts of that path that don't
>> match the filesystem with respect to case.  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.
> 
> I find this description somewhat misleading. "check-attr" at the plumbing
> level does take full path from the end user, but a common thing Git does
> is to ask the system to learn the prefix to the current directory with
> getcwd(3) append what fill_directory() enumerates as matching a pathspec
> given by the user with readdir(3) to the prefix to form the full path, and
> then feed that full path to git_check_attr().
> 
> Without anybody changing anything, we already do build the attr stack by
> "scanning the repository" in that case, no?

Well, kind of. What I meant by "scanning the repository", was having two separate mechanisms: one to build the attr stack, and one to scan it to get the attributes. Right now, the two operations are tied together and the stack is built as needed, and it is built using the same path string that the scan operation will use for checking for attributes. So, the leading paths will match.

When I wrote that commit message, I really was only thinking about a user-supplied path, but the focus should be on prepare_attr_stack(). The reason the leading paths to a .gitattributes file will necessarily match is because the attr stack is built using the path supplied to prepare_attr_stack(), and the same path string is used when scanning the stack to check for attributes. So each path that is supplied, regardless of whether its case matches the case in the file system or in the repository, will have an entry in the attr stack.

Maybe that last paragraph in the commit message should just be dropped. I think the preceding paragraph explains the purpose of the tests, and this last one doesn't really add any value.

Do you want me to resubmit or can you fix it up? I ask not because I am too lazy to do 'commit --amend' myself, but because you may prefer to receive one less patch in your inbox if you can easily apply the change yourself.

-Brandon
Previous: Junio C HamanoNext: Junio C Hamano
Message 11 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.