Code

[PATCH] git-ls-files: generalized pathspecs
authorLinus Torvalds <torvalds@osdl.org>
Mon, 22 Aug 2005 00:27:50 +0000 (17:27 -0700)
committerJunio C Hamano <junkio@cox.net>
Mon, 22 Aug 2005 19:58:03 +0000 (12:58 -0700)
commit56fc5108a2e82a5780179f05a46d3b8be507dc8c
treeef0de68612b416ce300eaba25bb562c43c0ac892
parent5be4efbefafcd5b81fe3d97e8395da1887b4902a
[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>
ls-files.c