multiple source file extensions

multiple source file extensions

[Thiago Farina]

Hey!

How do I tell 'git grep' to search only in .cc, .cpp and .h files?

>From http://gitster.livejournal.com/27674.html it seems possible to do
some filter, but in this article grep is told to search only in C
source files.

Bye!

-- 
Thiago Farina

Re: multiple source file extensions

[Josh Hagins]

If you're using a recent version of bash, you could enable the
'globstar' option:

    $ shopt -s globstar
    $ git grep 'pattern' **/*.{cc,cpp,h}

Does that work?

On Fri, May 1, 2015 at 8:40 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Hey!
>
> How do I tell 'git grep' to search only in .cc, .cpp and .h files?
>
> From http://gitster.livejournal.com/27674.html it seems possible to do
> some filter, but in this article grep is told to search only in C
> source files.
>
> Bye!
>
> --
> Thiago Farina
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Josh Hagins
College of Engineering
Cornell University '14
(843) 847-6008

Re: multiple source file extensions

[Jeff King]

On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:

> If you're using a recent version of bash, you could enable the
> 'globstar' option:
> 
>     $ shopt -s globstar
>     $ git grep 'pattern' **/*.{cc,cpp,h}
> 
> Does that work?

That will only pick up files that are in the working tree. Which is fine
for a stock "git grep" with no options, but would not be right for
grepping in the index or an older tree. For that, you can ask git to
glob for you:

  git grep pattern -- '*.cc' '*.cpp' '*.h'

Note that the "--" is important (it's what tells git "these are
pathspecs and not revision names"; normally git will guess if you are
passing literal pathnames, but the glob patterns fool the guessing
machinery).

Unfortunately there is no way to use curly braces with git's pathspec,
so you have to write out three separate `*` arguments rather than using
the shell-style {cc,cpp,h}.

-Peff

Re: multiple source file extensions

[Duy Nguyen]

On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:
> Unfortunately there is no way to use curly braces with git's pathspec,
> so you have to write out three separate `*` arguments rather than using
> the shell-style {cc,cpp,h}.

Noted. Need to add curly brace support in pathspec :-)

>   git grep pattern -- '*.cc' '*.cpp' '*.h'
> 
> Note that the "--" is important (it's what tells git "these are
> pathspecs and not revision names"; normally git will guess if you are
> passing literal pathnames, but the glob patterns fool the guessing
> machinery).

I'm having something like below to avoid the need for "--" in this
case. Probably a good time to throw it out and get some feedback. I
think it's a good change and does not compromise our ambiguity check..

This patch is modified just for reading so it may not build. The real
series takes care of "--" for both wildcard and magic pathspec. But I
don't think we need to see it now.

-- 8< --
Subject: [PATCH] Avoid the need of "--" when wildcard pathspec is used

When "--" is lacking from the command line and a command can take both
revs and paths, the idea is if an argument can be seen as both an
extended SHA-1 and a path, then "--" is required or git refuses to
continue. It's currently implemented as:

 (1) if an argument is rev, then it must not exist in worktree

 (2) else, it must exist in worktree

 (3) else, "--" is required.

These rules work for literal paths, but when non-literal pathspec is
involved, it almost always requires the user to add "--" because it
fails (2) and (1) is really rarely met (take "*.c" for example,
(1) is met if there is a ref named "*.c").

This patch modifies the rules a bit by considering any valid (*)
wildcard pathspec "exist in worktree". The rules become:

 (1) if an arg is a rev, then it must either exist in worktree or not
     be a valid wildcard pathspec.

 (2) else, it either exists in worktree or is a wildcard pathspec

 (3) else, "--" is required.

With the new rules, "--" is not needed most of the time when wildcard
pathspec is involved.
---
 setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/setup.c b/setup.c
index 979b13f..1055b82 100644
--- a/setup.c
+++ b/setup.c
@@ -140,7 +140,9 @@ int check_filename(const char *prefix, const char *arg)
 		if (arg[2] == '\0') /* ":/" is root dir, always exists */
 			return 1;
 		name = arg + 2;
-	} else if (prefix)
+	} else if (!no_wildcard(arg))
+		return 1;
+	else if (prefix)
 		name = prefix_filename(prefix, strlen(prefix), arg);
 	else
 		name = arg;
-- 
2.3.0.rc1.137.g477eb31

-- 8< --
 

Re: multiple source file extensions

[Duy Nguyen]

On Sat, May 2, 2015 at 9:04 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:
>> Unfortunately there is no way to use curly braces with git's pathspec,
>> so you have to write out three separate `*` arguments rather than using
>> the shell-style {cc,cpp,h}.
>
> Noted. Need to add curly brace support in pathspec :-)

Naah people can just do

git grep pattern -- '*'.{cc,cpp,h}

and bash will take care of expanding it into three separate arguments.
Obscure, but pathspec is also obscure..
-- 
Duy

Re: multiple source file extensions

[Jeff King]

On Sat, May 02, 2015 at 09:04:32AM +0700, Duy Nguyen wrote:

> Subject: [PATCH] Avoid the need of "--" when wildcard pathspec is used
> [..]
> This patch modifies the rules a bit by considering any valid (*)
> wildcard pathspec "exist in worktree". The rules become:
> 
>  (1) if an arg is a rev, then it must either exist in worktree or not
>      be a valid wildcard pathspec.
> 
>  (2) else, it either exists in worktree or is a wildcard pathspec
> 
>  (3) else, "--" is required.
> 
> With the new rules, "--" is not needed most of the time when wildcard
> pathspec is involved.

I like it. Since this is a DWIM code path anyway, I don't think it
should be a problem in practice (i.e., if you are trying to do something
crazy like match a literal path that has a '*' in it, you really should
be using "--" in the first place).

-Peff

Re: multiple source file extensions

[Jeff King]

On Sat, May 02, 2015 at 09:11:16AM +0700, Duy Nguyen wrote:

> On Sat, May 2, 2015 at 9:04 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> > On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:
> >> Unfortunately there is no way to use curly braces with git's pathspec,
> >> so you have to write out three separate `*` arguments rather than using
> >> the shell-style {cc,cpp,h}.
> >
> > Noted. Need to add curly brace support in pathspec :-)
> 
> Naah people can just do
> 
> git grep pattern -- '*'.{cc,cpp,h}
> 
> and bash will take care of expanding it into three separate arguments.
> Obscure, but pathspec is also obscure..

Thanks, I had a vague notion that I should be able to convince the shell
to do it for me, but of course "*.{cc,cpp,h}" doesn't work. I always
forget about breaking up parameters into two parts with different
quoting like this.

I agree we don't really need curly braces in pathspecs. :)

-Peff

Re: multiple source file extensions

[Eric Sunshine]

On Fri, May 1, 2015 at 10:35 PM, Jeff King <peff@peff.net> wrote:
> On Sat, May 02, 2015 at 09:11:16AM +0700, Duy Nguyen wrote:
>> On Sat, May 2, 2015 at 9:04 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>> > On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:
>> >> Unfortunately there is no way to use curly braces with git's pathspec,
>> >> so you have to write out three separate `*` arguments rather than using
>> >> the shell-style {cc,cpp,h}.
>> >
>> > Noted. Need to add curly brace support in pathspec :-)
>>
>> Naah people can just do
>>
>> git grep pattern -- '*'.{cc,cpp,h}
>>
>> and bash will take care of expanding it into three separate arguments.
>> Obscure, but pathspec is also obscure..
>
> Thanks, I had a vague notion that I should be able to convince the shell
> to do it for me, but of course "*.{cc,cpp,h}" doesn't work. I always
> forget about breaking up parameters into two parts with different
> quoting like this.
>
> I agree we don't really need curly braces in pathspecs. :)

However, neither POSIX shells nor the Windows command interpreter
support curly-brace alternation.

Re: multiple source file extensions

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

>> I agree we don't really need curly braces in pathspecs. :)
>
> However, neither POSIX shells nor the Windows command interpreter
> support curly-brace alternation.

Why "However"?  Neither of them offer it because their users do not
need it---why should we give it only when they are using Git and
only for the in-repo contents (we obviously cannot help when their
users want to refer to the working tree files)?

Re: multiple source file extensions

[Thiago Farina]

On Fri, May 1, 2015 at 10:11 PM, Jeff King <peff@peff.net> wrote:
> On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:
>
>> If you're using a recent version of bash, you could enable the
>> 'globstar' option:
>>
>>     $ shopt -s globstar
>>     $ git grep 'pattern' **/*.{cc,cpp,h}
>>
>> Does that work?
>
> That will only pick up files that are in the working tree. Which is fine
> for a stock "git grep" with no options, but would not be right for
> grepping in the index or an older tree. For that, you can ask git to
> glob for you:
>
>   git grep pattern -- '*.cc' '*.cpp' '*.h'
>
Is it possible to do a regex like the following?

".*\.[cChH]\(pp\)?"

http://stackoverflow.com/questions/277999/how-to-use-the-unix-find-command-to-find-all-the-cpp-and-h-files/3858879#3858879

-- 
Thiago Farina

Re: multiple source file extensions

[Jeff King]

On Mon, May 04, 2015 at 07:12:45PM -0300, Thiago Farina wrote:

> On Fri, May 1, 2015 at 10:11 PM, Jeff King <peff@peff.net> wrote:
> > On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:
> >
> >> If you're using a recent version of bash, you could enable the
> >> 'globstar' option:
> >>
> >>     $ shopt -s globstar
> >>     $ git grep 'pattern' **/*.{cc,cpp,h}
> >>
> >> Does that work?
> >
> > That will only pick up files that are in the working tree. Which is fine
> > for a stock "git grep" with no options, but would not be right for
> > grepping in the index or an older tree. For that, you can ask git to
> > glob for you:
> >
> >   git grep pattern -- '*.cc' '*.cpp' '*.h'
> >
> Is it possible to do a regex like the following?
> 
> ".*\.[cChH]\(pp\)?"

No, pathspecs are globs, not regexps. I think the idea has been floated
for supporting regexps, which you would activate something like:

  git grep pattern -- :(regexp)$your_regex_here

but nobody has implemented it. I'm not sure it actually saves you any
typing (besides which, your regexp does not match ".cc", which was in
the original).

-Peff

Re: multiple source file extensions

[Mikael Magnusson]

On Tue, May 5, 2015 at 5:43 AM, Jeff King <peff@peff.net> wrote:
> On Mon, May 04, 2015 at 07:12:45PM -0300, Thiago Farina wrote:
>
>> On Fri, May 1, 2015 at 10:11 PM, Jeff King <peff@peff.net> wrote:
>> > On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:
>> >
>> >> If you're using a recent version of bash, you could enable the
>> >> 'globstar' option:
>> >>
>> >>     $ shopt -s globstar
>> >>     $ git grep 'pattern' **/*.{cc,cpp,h}
>> >>
>> >> Does that work?
>> >
>> > That will only pick up files that are in the working tree. Which is fine
>> > for a stock "git grep" with no options, but would not be right for
>> > grepping in the index or an older tree. For that, you can ask git to
>> > glob for you:
>> >
>> >   git grep pattern -- '*.cc' '*.cpp' '*.h'
>> >
>> Is it possible to do a regex like the following?
>>
>> ".*\.[cChH]\(pp\)?"
>
> No, pathspecs are globs, not regexps. I think the idea has been floated
> for supporting regexps, which you would activate something like:
>
>   git grep pattern -- :(regexp)$your_regex_here
>
> but nobody has implemented it. I'm not sure it actually saves you any
> typing (besides which, your regexp does not match ".cc", which was in
> the original).

Remember that the more bells and whistles you add to pathspecs, the
less actual filenames can be conveniently tracked by git; *.c will be
expanded by the shell and passed literally to git, and if git then
interprets a bunch of stuff again, you could end up with a false
negative or positive match. Obviously files with * and ? in them are
already unsupported, try not to add more.

-- 
Mikael Magnusson

Re: multiple source file extensions

[Jeff King]

On Tue, May 05, 2015 at 07:30:00PM +0200, Mikael Magnusson wrote:

> >> ".*\.[cChH]\(pp\)?"
> >
> > No, pathspecs are globs, not regexps. I think the idea has been floated
> > for supporting regexps, which you would activate something like:
> >
> >   git grep pattern -- :(regexp)$your_regex_here
> >
> > but nobody has implemented it. I'm not sure it actually saves you any
> > typing (besides which, your regexp does not match ".cc", which was in
> > the original).
> 
> Remember that the more bells and whistles you add to pathspecs, the
> less actual filenames can be conveniently tracked by git; *.c will be
> expanded by the shell and passed literally to git, and if git then
> interprets a bunch of stuff again, you could end up with a false
> negative or positive match. Obviously files with * and ? in them are
> already unsupported, try not to add more.

I agree this is a problem, but I think we have already crossed that
bridge, and going forward:

  1. Any new bells and whistles will have to be activated explicitly
     (that's what the ":(regexp)" syntax is).

  2. The ":()" magic is already there, so add it to "*" and "?" in the
     list of obstacles.

  3. There is ":(literal)", "--literal-pathspecs", and $GIT_LITERAL_PATHSPECS
     to turn off all magic.

-Peff