{"thread":{"id":"39218","subject":"multiple source file extensions","startedAt":"2015-05-02T00:40:58Z","lastAt":"2015-05-05T19:12:38Z","messageCount":13,"participants":["Thiago Farina","Josh Hagins","Jeff King","Duy Nguyen","Eric Sunshine","Junio C Hamano","Mikael Magnusson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"260401","messageId":"CACnwZYed_aHzLsbkJVm=OnydXw-CPi-Zm9V7928rzvpaFMNENw@mail.gmail.com","threadId":"39218","inReplyTo":null,"subject":"multiple source file extensions","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2015-05-02T00:40:58Z","receivedAt":"2015-05-02T00:40:58Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"Hey!\n\nHow do I tell 'git grep' to search only in .cc, .cpp and .h files?\n\n>From http://gitster.livejournal.com/27674.html it seems possible to do\nsome filter, but in this article grep is told to search only in C\nsource files.\n\nBye!\n\n-- \nThiago Farina\n"},{"id":"260402","messageId":"CANuW5x3OBWNDnHeVbH7ZQaj5AUAingea6crJ0cF9AHFjcJE_bQ@mail.gmail.com","threadId":"39218","inReplyTo":"CACnwZYed_aHzLsbkJVm=OnydXw-CPi-Zm9V7928rzvpaFMNENw@mail.gmail.com","subject":"Re: multiple source file extensions","fromName":"Josh Hagins","fromEmail":"hagins.josh@gmail.com","sentAt":"2015-05-02T00:49:14Z","receivedAt":"2015-05-02T00:49:14Z","isPatch":false,"sender":{"key":"hagins.josh@gmail.com","avatar":null},"body":"If you're using a recent version of bash, you could enable the\n'globstar' option:\n\n $ shopt -s globstar\n $ git grep 'pattern' **/*.{cc,cpp,h}\n\nDoes that work?\n\nOn Fri, May 1, 2015 at 8:40 PM, Thiago Farina wrote:\n> Hey!\n>\n> How do I tell 'git grep' to search only in .cc, .cpp and .h files?\n>\n> From http://gitster.livejournal.com/27674.html it seems possible to do\n> some filter, but in this article grep is told to search only in C\n> source files.\n>\n> Bye!\n>\n> --\n> Thiago Farina\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n\n\n-- \nJosh Hagins\nCollege of Engineering\nCornell University '14\n(843) 847-6008\n"},{"id":"260404","messageId":"20150502011100.GB5634@peff.net","threadId":"39218","inReplyTo":"CANuW5x3OBWNDnHeVbH7ZQaj5AUAingea6crJ0cF9AHFjcJE_bQ@mail.gmail.com","subject":"Re: multiple source file extensions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-02T01:11:01Z","receivedAt":"2015-05-02T01:11:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:\n\n> If you're using a recent version of bash, you could enable the\n> 'globstar' option:\n> \n> $ shopt -s globstar\n> $ git grep 'pattern' **/*.{cc,cpp,h}\n> \n> Does that work?\n\nThat will only pick up files that are in the working tree. Which is fine\nfor a stock \"git grep\" with no options, but would not be right for\ngrepping in the index or an older tree. For that, you can ask git to\nglob for you:\n\n git grep pattern -- '*.cc' '*.cpp' '*.h'\n\nNote that the \"--\" is important (it's what tells git \"these are\npathspecs and not revision names\"; normally git will guess if you are\npassing literal pathnames, but the glob patterns fool the guessing\nmachinery).\n\nUnfortunately there is no way to use curly braces with git's pathspec,\nso you have to write out three separate `*` arguments rather than using\nthe shell-style {cc,cpp,h}.\n\n-Peff\n"},{"id":"260405","messageId":"20150502020431.GA15775@lanh","threadId":"39218","inReplyTo":"20150502011100.GB5634@peff.net","subject":"Re: multiple source file extensions","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-02T02:04:32Z","receivedAt":"2015-05-02T02:04:32Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:\n> Unfortunately there is no way to use curly braces with git's pathspec,\n> so you have to write out three separate `*` arguments rather than using\n> the shell-style {cc,cpp,h}.\n\nNoted. Need to add curly brace support in pathspec :-)\n\n> git grep pattern -- '*.cc' '*.cpp' '*.h'\n> \n> Note that the \"--\" is important (it's what tells git \"these are\n> pathspecs and not revision names\"; normally git will guess if you are\n> passing literal pathnames, but the glob patterns fool the guessing\n> machinery).\n\nI'm having something like below to avoid the need for \"--\" in this\ncase. Probably a good time to throw it out and get some feedback. I\nthink it's a good change and does not compromise our ambiguity check..\n\nThis patch is modified just for reading so it may not build. The real\nseries takes care of \"--\" for both wildcard and magic pathspec. But I\ndon't think we need to see it now.\n\n-- 8< --\nSubject: [PATCH] Avoid the need of \"--\" when wildcard pathspec is used\n\nWhen \"--\" is lacking from the command line and a command can take both\nrevs and paths, the idea is if an argument can be seen as both an\nextended SHA-1 and a path, then \"--\" is required or git refuses to\ncontinue. It's currently implemented as:\n\n (1) if an argument is rev, then it must not exist in worktree\n\n (2) else, it must exist in worktree\n\n (3) else, \"--\" is required.\n\nThese rules work for literal paths, but when non-literal pathspec is\ninvolved, it almost always requires the user to add \"--\" because it\nfails (2) and (1) is really rarely met (take \"*.c\" for example,\n(1) is met if there is a ref named \"*.c\").\n\nThis patch modifies the rules a bit by considering any valid (*)\nwildcard pathspec \"exist in worktree\". The rules become:\n\n (1) if an arg is a rev, then it must either exist in worktree or not\n be a valid wildcard pathspec.\n\n (2) else, it either exists in worktree or is a wildcard pathspec\n\n (3) else, \"--\" is required.\n\nWith the new rules, \"--\" is not needed most of the time when wildcard\npathspec is involved.\n---\n setup.c | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex 979b13f..1055b82 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -140,7 +140,9 @@ int check_filename(const char *prefix, const char *arg)\n \t\tif (arg[2] == '\\0') /* \":/\" is root dir, always exists */\n \t\t\treturn 1;\n \t\tname = arg + 2;\n-\t} else if (prefix)\n+\t} else if (!no_wildcard(arg))\n+\t\treturn 1;\n+\telse if (prefix)\n \t\tname = prefix_filename(prefix, strlen(prefix), arg);\n \telse\n \t\tname = arg;\n-- \n2.3.0.rc1.137.g477eb31\n\n-- 8< --\n \n"},{"id":"260406","messageId":"CACsJy8C2aztHWHP0_U8VWJxMrT2HE7aYBxDQTnSWS1TVwCnedw@mail.gmail.com","threadId":"39218","inReplyTo":"20150502020431.GA15775@lanh","subject":"Re: multiple source file extensions","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-05-02T02:11:16Z","receivedAt":"2015-05-02T02:11:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sat, May 2, 2015 at 9:04 AM, Duy Nguyen wrote:\n> On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:\n>> Unfortunately there is no way to use curly braces with git's pathspec,\n>> so you have to write out three separate `*` arguments rather than using\n>> the shell-style {cc,cpp,h}.\n>\n> Noted. Need to add curly brace support in pathspec :-)\n\nNaah people can just do\n\ngit grep pattern -- '*'.{cc,cpp,h}\n\nand bash will take care of expanding it into three separate arguments.\nObscure, but pathspec is also obscure..\n-- \nDuy\n"},{"id":"260408","messageId":"20150502023320.GB587@peff.net","threadId":"39218","inReplyTo":"20150502020431.GA15775@lanh","subject":"Re: multiple source file extensions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-02T02:33:21Z","receivedAt":"2015-05-02T02:33:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 02, 2015 at 09:04:32AM +0700, Duy Nguyen wrote:\n\n> Subject: [PATCH] Avoid the need of \"--\" when wildcard pathspec is used\n> [..]\n> This patch modifies the rules a bit by considering any valid (*)\n> wildcard pathspec \"exist in worktree\". The rules become:\n> \n> (1) if an arg is a rev, then it must either exist in worktree or not\n> be a valid wildcard pathspec.\n> \n> (2) else, it either exists in worktree or is a wildcard pathspec\n> \n> (3) else, \"--\" is required.\n> \n> With the new rules, \"--\" is not needed most of the time when wildcard\n> pathspec is involved.\n\nI like it. Since this is a DWIM code path anyway, I don't think it\nshould be a problem in practice (i.e., if you are trying to do something\ncrazy like match a literal path that has a '*' in it, you really should\nbe using \"--\" in the first place).\n\n-Peff\n"},{"id":"260409","messageId":"20150502023504.GC587@peff.net","threadId":"39218","inReplyTo":"CACsJy8C2aztHWHP0_U8VWJxMrT2HE7aYBxDQTnSWS1TVwCnedw@mail.gmail.com","subject":"Re: multiple source file extensions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-02T02:35:04Z","receivedAt":"2015-05-02T02:35:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 02, 2015 at 09:11:16AM +0700, Duy Nguyen wrote:\n\n> On Sat, May 2, 2015 at 9:04 AM, Duy Nguyen wrote:\n> > On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:\n> >> Unfortunately there is no way to use curly braces with git's pathspec,\n> >> so you have to write out three separate `*` arguments rather than using\n> >> the shell-style {cc,cpp,h}.\n> >\n> > Noted. Need to add curly brace support in pathspec :-)\n> \n> Naah people can just do\n> \n> git grep pattern -- '*'.{cc,cpp,h}\n> \n> and bash will take care of expanding it into three separate arguments.\n> Obscure, but pathspec is also obscure..\n\nThanks, I had a vague notion that I should be able to convince the shell\nto do it for me, but of course \"*.{cc,cpp,h}\" doesn't work. I always\nforget about breaking up parameters into two parts with different\nquoting like this.\n\nI agree we don't really need curly braces in pathspecs. :)\n\n-Peff\n"},{"id":"260420","messageId":"CAPig+cT8kP0NrmXXn-chBU+zjM_28NT5CVivda2NDs_mxuepzQ@mail.gmail.com","threadId":"39218","inReplyTo":"20150502023504.GC587@peff.net","subject":"Re: multiple source file extensions","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-02T07:11:37Z","receivedAt":"2015-05-02T07:11:37Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 1, 2015 at 10:35 PM, Jeff King wrote:\n> On Sat, May 02, 2015 at 09:11:16AM +0700, Duy Nguyen wrote:\n>> On Sat, May 2, 2015 at 9:04 AM, Duy Nguyen wrote:\n>> > On Fri, May 01, 2015 at 09:11:01PM -0400, Jeff King wrote:\n>> >> Unfortunately there is no way to use curly braces with git's pathspec,\n>> >> so you have to write out three separate `*` arguments rather than using\n>> >> the shell-style {cc,cpp,h}.\n>> >\n>> > Noted. Need to add curly brace support in pathspec :-)\n>>\n>> Naah people can just do\n>>\n>> git grep pattern -- '*'.{cc,cpp,h}\n>>\n>> and bash will take care of expanding it into three separate arguments.\n>> Obscure, but pathspec is also obscure..\n>\n> Thanks, I had a vague notion that I should be able to convince the shell\n> to do it for me, but of course \"*.{cc,cpp,h}\" doesn't work. I always\n> forget about breaking up parameters into two parts with different\n> quoting like this.\n>\n> I agree we don't really need curly braces in pathspecs. :)\n\nHowever, neither POSIX shells nor the Windows command interpreter\nsupport curly-brace alternation.\n"},{"id":"260450","messageId":"xmqqfv7ewg53.fsf@gitster.dls.corp.google.com","threadId":"39218","inReplyTo":"CAPig+cT8kP0NrmXXn-chBU+zjM_28NT5CVivda2NDs_mxuepzQ@mail.gmail.com","subject":"Re: multiple source file extensions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-03T02:26:16Z","receivedAt":"2015-05-03T02:26:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n>> I agree we don't really need curly braces in pathspecs. :)\n>\n> However, neither POSIX shells nor the Windows command interpreter\n> support curly-brace alternation.\n\nWhy \"However\"? Neither of them offer it because their users do not\nneed it---why should we give it only when they are using Git and\nonly for the in-repo contents (we obviously cannot help when their\nusers want to refer to the working tree files)?\n"},{"id":"260562","messageId":"CACnwZYdGKcdzgu1=Ysd_pxqeuSBpZu41i1EJBvBi4FqHzvV-Hw@mail.gmail.com","threadId":"39218","inReplyTo":"20150502011100.GB5634@peff.net","subject":"Re: multiple source file extensions","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2015-05-04T22:12:45Z","receivedAt":"2015-05-04T22:12:45Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"On Fri, May 1, 2015 at 10:11 PM, Jeff King wrote:\n> On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:\n>\n>> If you're using a recent version of bash, you could enable the\n>> 'globstar' option:\n>>\n>> $ shopt -s globstar\n>> $ git grep 'pattern' **/*.{cc,cpp,h}\n>>\n>> Does that work?\n>\n> That will only pick up files that are in the working tree. Which is fine\n> for a stock \"git grep\" with no options, but would not be right for\n> grepping in the index or an older tree. For that, you can ask git to\n> glob for you:\n>\n> git grep pattern -- '*.cc' '*.cpp' '*.h'\n>\nIs it possible to do a regex like the following?\n\n\".*\\.[cChH]\\(pp\\)?\"\n\nhttp://stackoverflow.com/questions/277999/how-to-use-the-unix-find-command-to-find-all-the-cpp-and-h-files/3858879#3858879\n\n-- \nThiago Farina\n"},{"id":"260580","messageId":"20150505034336.GA25194@peff.net","threadId":"39218","inReplyTo":"CACnwZYdGKcdzgu1=Ysd_pxqeuSBpZu41i1EJBvBi4FqHzvV-Hw@mail.gmail.com","subject":"Re: multiple source file extensions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-05T03:43:36Z","receivedAt":"2015-05-05T03:43:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 04, 2015 at 07:12:45PM -0300, Thiago Farina wrote:\n\n> On Fri, May 1, 2015 at 10:11 PM, Jeff King wrote:\n> > On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:\n> >\n> >> If you're using a recent version of bash, you could enable the\n> >> 'globstar' option:\n> >>\n> >> $ shopt -s globstar\n> >> $ git grep 'pattern' **/*.{cc,cpp,h}\n> >>\n> >> Does that work?\n> >\n> > That will only pick up files that are in the working tree. Which is fine\n> > for a stock \"git grep\" with no options, but would not be right for\n> > grepping in the index or an older tree. For that, you can ask git to\n> > glob for you:\n> >\n> > git grep pattern -- '*.cc' '*.cpp' '*.h'\n> >\n> Is it possible to do a regex like the following?\n> \n> \".*\\.[cChH]\\(pp\\)?\"\n\nNo, pathspecs are globs, not regexps. I think the idea has been floated\nfor supporting regexps, which you would activate something like:\n\n git grep pattern -- :(regexp)$your_regex_here\n\nbut nobody has implemented it. I'm not sure it actually saves you any\ntyping (besides which, your regexp does not match \".cc\", which was in\nthe original).\n\n-Peff\n"},{"id":"260596","messageId":"CAHYJk3TzZd8N6E+=nNi1jR36Zc5A7be8ZPL9jLU7c8uAdQJYBw@mail.gmail.com","threadId":"39218","inReplyTo":"20150505034336.GA25194@peff.net","subject":"Re: multiple source file extensions","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2015-05-05T17:30:00Z","receivedAt":"2015-05-05T17:30:00Z","isPatch":false,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"On Tue, May 5, 2015 at 5:43 AM, Jeff King wrote:\n> On Mon, May 04, 2015 at 07:12:45PM -0300, Thiago Farina wrote:\n>\n>> On Fri, May 1, 2015 at 10:11 PM, Jeff King wrote:\n>> > On Fri, May 01, 2015 at 08:49:14PM -0400, Josh Hagins wrote:\n>> >\n>> >> If you're using a recent version of bash, you could enable the\n>> >> 'globstar' option:\n>> >>\n>> >> $ shopt -s globstar\n>> >> $ git grep 'pattern' **/*.{cc,cpp,h}\n>> >>\n>> >> Does that work?\n>> >\n>> > That will only pick up files that are in the working tree. Which is fine\n>> > for a stock \"git grep\" with no options, but would not be right for\n>> > grepping in the index or an older tree. For that, you can ask git to\n>> > glob for you:\n>> >\n>> > git grep pattern -- '*.cc' '*.cpp' '*.h'\n>> >\n>> Is it possible to do a regex like the following?\n>>\n>> \".*\\.[cChH]\\(pp\\)?\"\n>\n> No, pathspecs are globs, not regexps. I think the idea has been floated\n> for supporting regexps, which you would activate something like:\n>\n> git grep pattern -- :(regexp)$your_regex_here\n>\n> but nobody has implemented it. I'm not sure it actually saves you any\n> typing (besides which, your regexp does not match \".cc\", which was in\n> the original).\n\nRemember that the more bells and whistles you add to pathspecs, the\nless actual filenames can be conveniently tracked by git; *.c will be\nexpanded by the shell and passed literally to git, and if git then\ninterprets a bunch of stuff again, you could end up with a false\nnegative or positive match. Obviously files with * and ? in them are\nalready unsupported, try not to add more.\n\n-- \nMikael Magnusson\n"},{"id":"260612","messageId":"20150505191238.GC10463@peff.net","threadId":"39218","inReplyTo":"CAHYJk3TzZd8N6E+=nNi1jR36Zc5A7be8ZPL9jLU7c8uAdQJYBw@mail.gmail.com","subject":"Re: multiple source file extensions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-05-05T19:12:38Z","receivedAt":"2015-05-05T19:12:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 05, 2015 at 07:30:00PM +0200, Mikael Magnusson wrote:\n\n> >> \".*\\.[cChH]\\(pp\\)?\"\n> >\n> > No, pathspecs are globs, not regexps. I think the idea has been floated\n> > for supporting regexps, which you would activate something like:\n> >\n> > git grep pattern -- :(regexp)$your_regex_here\n> >\n> > but nobody has implemented it. I'm not sure it actually saves you any\n> > typing (besides which, your regexp does not match \".cc\", which was in\n> > the original).\n> \n> Remember that the more bells and whistles you add to pathspecs, the\n> less actual filenames can be conveniently tracked by git; *.c will be\n> expanded by the shell and passed literally to git, and if git then\n> interprets a bunch of stuff again, you could end up with a false\n> negative or positive match. Obviously files with * and ? in them are\n> already unsupported, try not to add more.\n\nI agree this is a problem, but I think we have already crossed that\nbridge, and going forward:\n\n 1. Any new bells and whistles will have to be activated explicitly\n (that's what the \":(regexp)\" syntax is).\n\n 2. The \":()\" magic is already there, so add it to \"*\" and \"?\" in the\n list of obstacles.\n\n 3. There is \":(literal)\", \"--literal-pathspecs\", and $GIT_LITERAL_PATHSPECS\n to turn off all magic.\n\n-Peff\n"}]}