summaryrefslogtreecommitdiff
path: root/object.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@osdl.org>2005-08-21 17:27:50 -0700
committerJunio C Hamano <junkio@cox.net>2005-08-22 12:58:03 -0700
commit56fc5108a2e82a5780179f05a46d3b8be507dc8c (patch)
treeef0de68612b416ce300eaba25bb562c43c0ac892 /object.h
parent5be4efbefafcd5b81fe3d97e8395da1887b4902a (diff)
downloadgit-56fc5108a2e82a5780179f05a46d3b8be507dc8c.tar.gz
[PATCH] git-ls-files: generalized pathspecs
This generalizes the git "glob" string to be a lot more like the git-diff-* pathspecs (but there are still differences: the diff family doesn't do any globbing, and because the diff family always generates the full native pathname, it doesn't have the issue with ".."). It does three things: - it allows multiple matching strings, ie you can do things like git-ls-files arch/i386/ include/asm-i386/ | xargs grep pattern - the "matching" criteria is a combination of "exact path component match" (the same as the git-diff-* family), and "fnmatch()". However, you should be careful with the confusion between the git-ls-files internal globbing and the standard shell globbing, ie git-ls-files fs/*.c does globbing in the shell, and does something totally different from git-ls-files 'fs/*.c' which does the globbing inside git-ls-files. The latter has _one_ pathspec with a wildcard, and will match any .c file anywhere under the fs/ directory, while the former has been expanded by the shell into having _lots_ of pathspec entries, all of which are just in the top-level fs/ subdirectory. They will happily be matched exactly, but we will thus miss all the subdirectories under fs/. As a result, the first one will (on the current kernel) match 55 files, while the second one will match 664 files! - it uses the generic path prefixing, so that ".." and friends at the beginning of the path spec work automatically NOTE! When generating relative pathname output (the default), a pathspec that causes the base to be outside the current working directory will be rejected with an error message like: fatal: git-ls-files: cannot generate relative filenames containing '..' because we do not actually generate ".." in the output. However, the ".." format works fine for the --full-name case: cd arch/i386/kernel git-ls-files --full-name ../mm/ results in arch/i386/mm/Makefile arch/i386/mm/boot_ioremap.c arch/i386/mm/discontig.c arch/i386/mm/extable.c arch/i386/mm/fault.c arch/i386/mm/highmem.c arch/i386/mm/hugetlbpage.c arch/i386/mm/init.c arch/i386/mm/ioremap.c arch/i386/mm/mmap.c arch/i386/mm/pageattr.c arch/i386/mm/pgtable.c Perhaps more commonly, the generic path prefixing means that "." and "./" automatically get simplified and work properly. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'object.h')
0 files changed, 0 insertions, 0 deletions