summaryrefslogtreecommitdiff
path: root/compat/regex
diff options
context:
space:
mode:
authorLibravatar Brandon Casey <drafnel@gmail.com>2011-10-11 10:53:31 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2011-10-11 09:43:05 -0700
commit6eba6210d9824445c29b75f9c618abbec5184afd (patch)
tree12d2b31235863cb72405475eda0a7c59a2477028 /compat/regex
parentattr: read core.attributesfile from git_default_core_config (diff)
downloadtgif-6eba6210d9824445c29b75f9c618abbec5184afd.tar.xz
attr.c: respect core.ignorecase when matching attribute patterns
When core.ignorecase is true, the file globs configured in the .gitattributes file should be matched case-insensitively against the paths in the working directory. Let's do so. Plus, add some tests. 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 will currently only match the portion of the path below the directory holding the .gitignore file according to the setting of core.ignorecase. This is also partly future-proofing. 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. If someone makes a change like that in the future, these tests will notice. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat/regex')
0 files changed, 0 insertions, 0 deletions