Re: How to use path limiting (using a glob)?

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 11, 2009, 19:40 UTC
Message-ID: <alpine.LFD.2.00.0902111129190.3590@localhost.localdomain>
In-Reply-To: <20090211191432.GC27232@m62s10.vlinux.de>

On Wed, 11 Feb 2009, Peter Baumann wrote:

Show 7 quoted lines

> after reading Junio's nice blog today where he explained how to use git grep
> efficiently, I saw him using a glob to match for the interesting files:
> 
> 	 $ git grep -e ';;' -- '*.c'
> 
> Is it possible to have the same feature in git diff and the revision
> machinery?

Not really. Git has two different kinds of path limiters, and they are really really different.

 - the "walk current index/directory recursively" kind that "git ls-files" 
   uses, which takes a 'fnmatch()' type path regexp (not a real regexp, 
   but the kind you're used to with shell)

   NOTE! On purpose, we don't set the FNM_PATHNAME, so "*.c" here is 
   different from *.c in shell (it's more like "**.c" in tcsh). IOW, * 
   matches '/' too, and will walk subdirectories.

 - the "revision limiter" pathspec. This is *not* a regexp, it's a pure 
   prefix matcher, for a very simple reason: performance.

Show 7 quoted lines

> 	$ cd $path_to_your_git_src_dir
> 	$ git log master -p -- '*.h'
> 	.... No commit shown 
> 
> 	$ git diff --name-only v1.5.0  v1.6.0 -- '*.c'
> 
> and both don't return anything.

Yeah, in the revision matcher you can still depend on the shell expansion, and it will do _almost_ the right thing. So if you do

	git log master -p *.c

without the quotes, the shell expansion will work, and that in turn will give a set of filenames that "git log" will restrict the log to. HOWEVER, it's not a real wildcard - it's literally looking at what you have now in your current working directory, and saying "give me the logs of those pathnames", not "give me the logs of everything ending with .c".

We _could_ make the revision limiter understand fnmatch-style patterns, but quite frankly, it's very very expensive - too expensive to be useful for big repositories. The point about only matching prefixes is that it allows the revision limiter to not even walk into subdirectories that don't match, but if you do the "*.c" kind of pattern, now the revision code has to look up every tree recursively. That code is also _extremely_ performance-critical, so we really don't want to use fnmatch() when we can currently use just "memcmp()".

So yes, it's kind of odd how we have two totally different concepts of pathname patterns, but it's probably easiest to remember that "'git grep' is just special".

		Linus