{"thread":{"id":"26615","subject":"git-grep to operate across who repository and not just CWD?","startedAt":"2011-02-28T00:17:28Z","lastAt":"2011-03-24T14:46:57Z","messageCount":46,"participants":["David Chanters","Michael J Gruber","Jay Soffian","Junio C Hamano","Phil Hord","Nguyen Thai Ngoc Duy","James Pickens","Sverre Rabbelier","Miles Bader","Nguyễn Thái Ngọc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"162392","messageId":"AANLkTimnOSzF1o-fX-n7b26Qx2aLP3aU3pTMGY_f5hKy@mail.gmail.com","threadId":"26615","inReplyTo":null,"subject":"git-grep to operate across who repository and not just CWD?","fromName":"David Chanters","fromEmail":"david.chanters@googlemail.com","sentAt":"2011-02-28T00:17:28Z","receivedAt":"2011-02-28T00:17:28Z","isPatch":false,"sender":{"key":"david.chanters@googlemail.com","avatar":null},"body":"Hi all,\n\n[ Please Cc me as I am not subscribed to this list, thanks. ]\n\nI'm wondering if there's an easy way to get git-grep (and I suppose\nother commands which operate on a per-repository level rather than\nper-tree) to work across the whole repository?\n\nOften I will be in the depths of my git repository, run \"git grep\n--options 'search string'\", to find no results. Of course, then I\nremember that git grep doesn't work across the whole repository, it\nworks like normal grep, and only considers the CWD onwards.\nTypically I end up cursing, using {push,pop}d to recall where I am,\ncd'ing to the root of the repository and running \"git grep\" from there\nand then poping my CWD to go back to where I was.\n\nIs there some clever trickery or command-line flag I've not read about\nin the \"git-grep\" man page to make this idea more seamless?\n\nTIA,\n\nDavid\n"},{"id":"162411","messageId":"4D6B6A8B.20709@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTimnOSzF1o-fX-n7b26Qx2aLP3aU3pTMGY_f5hKy@mail.gmail.com","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-28T09:27:39Z","receivedAt":"2011-02-28T09:27:39Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"David Chanters venit, vidit, dixit 28.02.2011 01:17:\n> Hi all,\n> \n> [ Please Cc me as I am not subscribed to this list, thanks. ]\n> \n> I'm wondering if there's an easy way to get git-grep (and I suppose\n> other commands which operate on a per-repository level rather than\n> per-tree) to work across the whole repository?\n> \n> Often I will be in the depths of my git repository, run \"git grep\n> --options 'search string'\", to find no results. Of course, then I\n> remember that git grep doesn't work across the whole repository, it\n> works like normal grep, and only considers the CWD onwards.\n> Typically I end up cursing, using {push,pop}d to recall where I am,\n> cd'ing to the root of the repository and running \"git grep\" from there\n> and then poping my CWD to go back to where I was.\n> \n> Is there some clever trickery or command-line flag I've not read about\n> in the \"git-grep\" man page to make this idea more seamless?\n\ngit grep -- $(git rev-parse --show-cdup)\n\nis the best we have right now. I think we're still looking for a good\nway to denote \"root of repo\" (like \".\" for cwd).\n\nAlso, we're thinking of changing a few defaults (to repo-wide), but \"git\ngrep\" is meant to stay close to ordinary grep.\n\nMichael\n"},{"id":"162444","messageId":"AANLkTimJWeZLJbPndTyE0EUW3R9EC=yV55jhHbpZnnJn@mail.gmail.com","threadId":"26615","inReplyTo":"4D6B6A8B.20709@drmicha.warpmail.net","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-28T15:27:06Z","receivedAt":"2011-02-28T15:27:06Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 28, 2011 at 4:27 AM, Michael J Gruber\n wrote:\n> git grep -- $(git rev-parse --show-cdup)\n>\n> is the best we have right now. I think we're still looking for a good\n> way to denote \"root of repo\" (like \".\" for cwd).\n>\n> Also, we're thinking of changing a few defaults (to repo-wide), but \"git\n> grep\" is meant to stay close to ordinary grep.\n\nI had the crazy thought that if git had a --cdup option, then this\nwould work with any command you wanted to run from the top:\n\n git --cdup grep ...\n\nMaybe that's the best way to expose \"from the top please\" generically?\n\nj.\n"},{"id":"162460","messageId":"7vk4gkhuw4.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"AANLkTimJWeZLJbPndTyE0EUW3R9EC=yV55jhHbpZnnJn@mail.gmail.com","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-28T18:32:59Z","receivedAt":"2011-02-28T18:32:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> I had the crazy thought that if git had a --cdup option, then this\n> would work with any command you wanted to run from the top:\n>\n> git --cdup grep ...\n>\n> Maybe that's the best way to expose \"from the top please\" generically?\n\nWe tend to give --full-tree option to individual subcommands where it\nmakes sense to get the same effect.\n\nOne problem with a global \"git --cdup\" is to sensibly handle pathspecs\ngiven from the command line. You would likely want\n\n\t$ cd Documentation\n $ git --cdup grep -e info pu Makefile '*.txt'\n\nto still refer to Makefile relative to Documentation/ directory (imagine\ntyping \"Makef\" to complete while forming that command line) while\nlooking for '*.txt' files everywhere in the tree, but only individual\ncommands can tell which parameters are pathspec in argv[]. Hence the\nsubcommands have to be aware of the wish (--cdup or --full-tree) of the\nuser to affect the full tree, not limited to the current working\ndirectory.\n"},{"id":"162461","messageId":"7vd3mchumz.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"7vk4gkhuw4.fsf@alter.siamese.dyndns.org","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-28T18:38:28Z","receivedAt":"2011-02-28T18:38:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jay Soffian writes:\n>\n>> I had the crazy thought that if git had a --cdup option, then this\n>> would work with any command you wanted to run from the top:\n>>\n>> git --cdup grep ...\n>>\n>> Maybe that's the best way to expose \"from the top please\" generically?\n>\n> We tend to give --full-tree option to individual subcommands where it\n> makes sense to get the same effect.\n>\n> One problem with a global \"git --cdup\" is ...\n\nHaving said all that, here is a tip of the day. I have this in my .bashrc\nfor interactive shells.\n\n cdup () {\n local eh\n eh=$(git rev-parse --is-inside-work-tree) || return\n case \"$eh\" in\n true)\n eh=$(git rev-parse --show-toplevel)\n test -z \"$eh\" || cd \"$eh\"\n ;;\n false)\n eh=$(git rev-parse --git-dir) || return\n cd \"$eh\" || return\n eh=$(git rev-parse --is-bare-repository) || return\n test \"z$eh\" = ztrue || cd ..\n ;;\n esac\n }\n\nand I can say\n\n\t$ cd Documentation/howto\n $ editor *.txt\n $ cdup\n\nto come back to the toplevel after having worked somewhere deep in the\nmine.\n"},{"id":"162485","messageId":"4D6C20F6.3070905@cisco.com","threadId":"26615","inReplyTo":"4D6B6A8B.20709@drmicha.warpmail.net","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-02-28T22:25:58Z","receivedAt":"2011-02-28T22:25:58Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"(cc list: Pardon this duplicate attempt)\n\nOn 02/28/2011 04:27 AM, Michael J Gruber wrote:\n> David Chanters venit, vidit, dixit 28.02.2011 01:17:\n>> > Hi all,\n>> > \n>> > [ Please Cc me as I am not subscribed to this list, thanks. ]\n>> > \n>> > I'm wondering if there's an easy way to get git-grep (and I suppose\n>> > other commands which operate on a per-repository level rather than\n>> > per-tree) to work across the whole repository?\n> git grep -- $(git rev-parse --show-cdup)\n>\n> is the best we have right now. I think we're still looking for a good\n> way to denote \"root of repo\" (like \".\" for cwd).\n>\n> Also, we're thinking of changing a few defaults (to repo-wide), but \"git\n> grep\" is meant to stay close to ordinary grep.\n\nBut git grep is different than grep in exactly the \"files selection\"\narea. With grep, I always have to specify the files to search. With\ngit-grep, I don't.\n\nOridinary grep with no paths fails (reads stdin), so when I make this\nmistake it is always immediately evident. I retry the command with\npaths/wildcards. But git-grep with no path \"works\" and I am likely to\nforget that it worked only on my $PWD.\n\ngit-grep also includes subdirectories and excludes untracked files by\ndefault. This makes git-grep feel like the \"repository grep\" tool that\nit is. The fact that it does _not_ search from the top of the repository\nby default seems (to me) to be the only oddball case.\n\nI would be much more comfortable with David's proposed option turned on\nalways. When I want to search \"here\", I can add a dot.\n\n git grep foo # search the whole repository\n git grep foo -- . # Search only from $PWD\n\nMaybe it's dangerous as an always-on option, as it can break scripts. \nAnd I'd be happy-ish even with a --full-tree option. But I think I\nwould eventually alias it so it always does what I expect.\n\nI know that's not what the original question was, but it's the behavior\nI often erroneously expect.\n\nThoughts?\n\nPhil\n"},{"id":"162517","messageId":"4D6CA8B7.5000608@drmicha.warpmail.net","threadId":"26615","inReplyTo":"4D6C20F6.3070905@cisco.com","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T08:05:11Z","receivedAt":"2011-03-01T08:05:11Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Phil Hord venit, vidit, dixit 28.02.2011 23:25:\n> (cc list: Pardon this duplicate attempt)\n> \n> On 02/28/2011 04:27 AM, Michael J Gruber wrote:\n>> David Chanters venit, vidit, dixit 28.02.2011 01:17:\n>>>> Hi all,\n>>>>\n>>>> [ Please Cc me as I am not subscribed to this list, thanks. ]\n>>>>\n>>>> I'm wondering if there's an easy way to get git-grep (and I suppose\n>>>> other commands which operate on a per-repository level rather than\n>>>> per-tree) to work across the whole repository?\n>> git grep -- $(git rev-parse --show-cdup)\n>>\n>> is the best we have right now. I think we're still looking for a good\n>> way to denote \"root of repo\" (like \".\" for cwd).\n>>\n>> Also, we're thinking of changing a few defaults (to repo-wide), but \"git\n>> grep\" is meant to stay close to ordinary grep.\n> \n> But git grep is different than grep in exactly the \"files selection\"\n> area. With grep, I always have to specify the files to search. With\n> git-grep, I don't.\n> \n> Oridinary grep with no paths fails (reads stdin), so when I make this\n> mistake it is always immediately evident. I retry the command with\n> paths/wildcards. But git-grep with no path \"works\" and I am likely to\n> forget that it worked only on my $PWD.\n> \n> git-grep also includes subdirectories and excludes untracked files by\n> default. This makes git-grep feel like the \"repository grep\" tool that\n> it is. The fact that it does _not_ search from the top of the repository\n> by default seems (to me) to be the only oddball case.\n> \n> I would be much more comfortable with David's proposed option turned on\n> always. When I want to search \"here\", I can add a dot.\n> \n> git grep foo # search the whole repository\n> git grep foo -- . # Search only from $PWD\n> \n> Maybe it's dangerous as an always-on option, as it can break scripts. \n> And I'd be happy-ish even with a --full-tree option. But I think I\n> would eventually alias it so it always does what I expect.\n> \n> I know that's not what the original question was, but it's the behavior\n> I often erroneously expect.\n\nI would love \"git grep\" to be repowise, with the simple \"git grep .\" to\nmake it relative to cwd. We've discussed making more commands repowise,\nand the consensus (which I've stated above, accepting the majority vote)\nwas that some should stay, e.g. git-grep. The discussion started with\n\n\n\nand the consensus is stated here:\n\n\n\nThis does not prevent you from submitting a \"--full-tree\" patch for\ngit-grep, of course.\n\nMichael\n"},{"id":"162518","messageId":"AANLkTim78nQgS7NPXWErQyrqmt41OUXY6gzJmMwjtxo9@mail.gmail.com","threadId":"26615","inReplyTo":"4D6CA8B7.5000608@drmicha.warpmail.net","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T08:16:05Z","receivedAt":"2011-03-01T08:16:05Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 3:05 PM, Michael J Gruber\n wrote:\n> I would love \"git grep\" to be repowise, with the simple \"git grep .\" to\n> make it relative to cwd. We've discussed making more commands repowise,\n> and the consensus (which I've stated above, accepting the majority vote)\n> was that some should stay, e.g. git-grep. The discussion started with\n>\n> \n>\n> and the consensus is stated here:\n>\n> \n>\n> This does not prevent you from submitting a \"--full-tree\" patch for\n> git-grep, of course.\n\nIn fact Junio wrote one:\n\nhttp://mid.gmane.org/7vk4xggv27.fsf@alter.siamese.dyndns.org\n\nIf I remember correctly, it was dropped because of the interaction\nwith pathspecs (relative to cwd vs to worktree's root). I'd be great\nif someone can pick it up and finish it.\n-- \nDuy\n"},{"id":"162522","messageId":"4D6CB45F.1030800@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTim78nQgS7NPXWErQyrqmt41OUXY6gzJmMwjtxo9@mail.gmail.com","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T08:54:55Z","receivedAt":"2011-03-01T08:54:55Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 09:16:\n> On Tue, Mar 1, 2011 at 3:05 PM, Michael J Gruber\n> wrote:\n>> I would love \"git grep\" to be repowise, with the simple \"git grep .\" to\n>> make it relative to cwd. We've discussed making more commands repowise,\n>> and the consensus (which I've stated above, accepting the majority vote)\n>> was that some should stay, e.g. git-grep. The discussion started with\n>>\n>> \n>>\n>> and the consensus is stated here:\n>>\n>> \n>>\n>> This does not prevent you from submitting a \"--full-tree\" patch for\n>> git-grep, of course.\n> \n> In fact Junio wrote one:\n> \n> http://mid.gmane.org/7vk4xggv27.fsf@alter.siamese.dyndns.org\n\nOh yes, thanks for reminding me. And guess who replied first back then?\nOh well...\n\n> If I remember correctly, it was dropped because of the interaction\n> with pathspecs (relative to cwd vs to worktree's root). I'd be great\n> if someone can pick it up and finish it.\n\nRereading that thread, I don't think there was any objection against\n\"--full-tree\", but it suffered from DTD (discussed-to-death). To make it\nreally usefull, one would need a short-cut/option/whatever, and that's\nwhere the discussion went astray. I have an idea, though :)\n\nMichael\n"},{"id":"162531","messageId":"AANLkTik1_f7s0OUK9Q-BER9RkOdWiB=ZeN76HnCgmj+3@mail.gmail.com","threadId":"26615","inReplyTo":"4D6CB45F.1030800@drmicha.warpmail.net","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T09:32:24Z","receivedAt":"2011-03-01T09:32:24Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 3:54 PM, Michael J Gruber\n wrote:\n>> If I remember correctly, it was dropped because of the interaction\n>> with pathspecs (relative to cwd vs to worktree's root). I'd be great\n>> if someone can pick it up and finish it.\n>\n> Rereading that thread, I don't think there was any objection against\n> \"--full-tree\", but it suffered from DTD (discussed-to-death). To make it\n> really usefull, one would need a short-cut/option/whatever, and that's\n> where the discussion went astray. I have an idea, though :)\n\nNo it was in next or pu for a while, then got dropped out. I don't\nremember what \"what's cooking\" mail though.\n-- \nDuy\n"},{"id":"162532","messageId":"AANLkTi=xrnxUtkayyW1Merh49N6uHy5p-GMrYe6+p==t@mail.gmail.com","threadId":"26615","inReplyTo":"AANLkTik1_f7s0OUK9Q-BER9RkOdWiB=ZeN76HnCgmj+3@mail.gmail.com","subject":"Re: git-grep to operate across who repository and not just CWD?","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T09:44:13Z","receivedAt":"2011-03-01T09:44:13Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 4:32 PM, Nguyen Thai Ngoc Duy wrote:\n> No it was in next or pu for a while, then got dropped out. I don't\n> remember what \"what's cooking\" mail though.\n\nI got it, 1dbdbcb (What's cooking (2009/12 #04)):\n\n+The interaction with this option and pathspecs need to be worked out\n+better. I _think_ \"grep --full-tree -e pattern -- '*.h'\" should find from\n+all the header files in the tree, for example.\n-- \nDuy\n"},{"id":"162533","messageId":"cover.1298972832.git.git@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTi=xrnxUtkayyW1Merh49N6uHy5p-GMrYe6+p==t@mail.gmail.com","subject":"[PATCH/POC 0/2] grep --full-tree","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T09:53:28Z","receivedAt":"2011-03-01T09:53:28Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"I think we could make --full-tree useful with pathspecs like below. There are\nno tests yet and no doc because I actually favour a pathspec based solution,\nand that would possibly lead to mixed pathspecs (relative+absolute),\ninteracting badly with an overall option.\n\nBut I have to look at the pathspec stuff first. Or maybe at format-patch, if I\ninterpret the latest What's Cooking correctly...\n\nJunio C Hamano (1):\n grep: --full-tree\n\nMichael J Gruber (1):\n grep: make --full-tree work with pathspecs\n\n builtin/grep.c | 7 +++++--\n 1 files changed, 5 insertions(+), 2 deletions(-)\n\n-- \n1.7.4.1.257.gb09fa\n"},{"id":"162534","messageId":"f179d6fa62001ada34a4236327eda985e09416b1.1298972832.git.git@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTi=xrnxUtkayyW1Merh49N6uHy5p-GMrYe6+p==t@mail.gmail.com","subject":"[PATCH/RFC 1/2] grep: --full-tree","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T09:53:29Z","receivedAt":"2011-03-01T09:53:29Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"From: Junio C Hamano \n\nWhile working inside a deep subdirectory, it sometimes is necessary to\nfind a string you see in a file you are working on from the files in the\nentire project. This is especially true when you are dipping your toe\ninto an unfamiliar project.\n\nBy default, \"git grep\" limits its search space to the current directory\nand below (i.e. as if \"-r .\" is specified), and it is rather cumbersome to\nrepeat ../ as many times as necessary. This new option tells \"git grep\"\nnot to limit the search space to the current directory.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/grep.c | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex 5afee2f..d005528 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -728,6 +728,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n {\n \tint hit = 0;\n \tint cached = 0;\n+\tint full_tree = 0;\n \tint seen_dashdash = 0;\n \tint external_grep_allowed__ignored;\n \tconst char *show_in_pager = NULL, *default_pager = \"dummy\";\n@@ -773,6 +774,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\tOPT_BIT('H', NULL, &opt.pathname, \"show filenames\", 1),\n \t\tOPT_NEGBIT(0, \"full-name\", &opt.relative,\n \t\t\t\"show filenames relative to top directory\", 1),\n+\t\tOPT_BIT(0, \"full-tree\", &full_tree,\n+\t\t\t\"search from the top of the tree\", 1),\n \t\tOPT_BOOLEAN('l', \"files-with-matches\", &opt.name_only,\n \t\t\t\"show only filenames instead of matching lines\"),\n \t\tOPT_BOOLEAN(0, \"name-only\", &opt.name_only,\n@@ -957,7 +960,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \n \tif (i < argc)\n \t\tpaths = get_pathspec(prefix, argv + i);\n-\telse if (prefix) {\n+\telse if (prefix && !full_tree) {\n \t\tpaths = xcalloc(2, sizeof(const char *));\n \t\tpaths[0] = prefix;\n \t\tpaths[1] = NULL;\n-- \n1.7.4.1.257.gb09fa\n"},{"id":"162535","messageId":"3719d9a120eef618d875629662a87e715de55d4e.1298972832.git.git@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTi=xrnxUtkayyW1Merh49N6uHy5p-GMrYe6+p==t@mail.gmail.com","subject":"[PATCH/RFC 2/2] grep: make --full-tree work with pathspecs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T09:53:30Z","receivedAt":"2011-03-01T09:53:30Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"When --full-tree is given, make the pathspecs be applied relative to the\nroot. That way, \"git grep --full-tree expr -- *.c\" looks in all C files in\nthe repo.\n\nSigned-off-by: Michael J Gruber \n---\n builtin/grep.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex d005528..e0a75a7 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -959,7 +959,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t}\n \n \tif (i < argc)\n-\t\tpaths = get_pathspec(prefix, argv + i);\n+\t\tpaths = get_pathspec(!full_tree ? prefix : NULL, argv + i);\n \telse if (prefix && !full_tree) {\n \t\tpaths = xcalloc(2, sizeof(const char *));\n \t\tpaths[0] = prefix;\n-- \n1.7.4.1.257.gb09fa\n"},{"id":"162536","messageId":"bc49592f5e524a0d12aa55eeca1c5ca659b6525f.1298974647.git.git@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTi=xrnxUtkayyW1Merh49N6uHy5p-GMrYe6+p==t@mail.gmail.com","subject":"[PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T10:21:17Z","receivedAt":"2011-03-01T10:21:17Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Introduce a leading ':' as the notation for repo-wide pathspecs.\n\nThis is in line with our treeish:path notation which defaults to\nrepowide paths.\n\nHeck: Even ':./path' works for pathspecs, and I have no clue why!\n\nSigned-off-by: Michael J Gruber \n---\nI have not tested this for adverse side effects, only for the intended ones\nwith \"git grep\".\n\nIt's an alternative to \"--full-tree\", more far reaching, maybe too far.\nBut we seem to accept that paths do not start with ':', and that notation\nshould make msys happy, but what do I know about msys.\n\n(one could stick this into prefix_path() rather than get_pathspec(), but that\nwould be way too far)\n\n setup.c | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/setup.c b/setup.c\nindex 021d013..e7b05f0 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -147,7 +147,11 @@ const char **get_pathspec(const char *prefix, const char **pathspec)\n \tdst = pathspec;\n \tprefixlen = prefix ? strlen(prefix) : 0;\n \twhile (*src) {\n-\t\tconst char *p = prefix_path(prefix, prefixlen, *src);\n+\t\tconst char *p;\n+\t\tif ((*src)[0] == ':')\n+\t\t\tp = prefix_path(NULL, 0, (*src)+1);\n+\t\telse\n+\t\t\tp = prefix_path(prefix, prefixlen, *src);\n \t\t*(dst++) = p;\n \t\tsrc++;\n \t}\n-- \n1.7.4.1.257.gb09fa\n"},{"id":"162538","messageId":"AANLkTimJ7QsPTW0Vm9JgYVbcRQRoTnuiXUxOK=0unk6P@mail.gmail.com","threadId":"26615","inReplyTo":"bc49592f5e524a0d12aa55eeca1c5ca659b6525f.1298974647.git.git@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T11:13:12Z","receivedAt":"2011-03-01T11:13:12Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2011/3/1 Michael J Gruber :\n> Introduce a leading ':' as the notation for repo-wide pathspecs.\n>\n> This is in line with our treeish:path notation which defaults to\n> repowide paths.\n>\n> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n\nIf you are going to turn pathspecs into something more complex,\nreserve room for future extension. I have negative pathspecs that can\nutilize it.\n\nI take it, from now on people must refer file name ':foo' as './:foo'\nwith your patch?\n-- \nDuy\n"},{"id":"162539","messageId":"4D6CD593.2090705@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTimJ7QsPTW0Vm9JgYVbcRQRoTnuiXUxOK=0unk6P@mail.gmail.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T11:16:35Z","receivedAt":"2011-03-01T11:16:35Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:13:\n> 2011/3/1 Michael J Gruber :\n>> Introduce a leading ':' as the notation for repo-wide pathspecs.\n>>\n>> This is in line with our treeish:path notation which defaults to\n>> repowide paths.\n>>\n>> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n> \n> If you are going to turn pathspecs into something more complex,\n> reserve room for future extension. I have negative pathspecs that can\n> utilize it.\n> \n> I take it, from now on people must refer file name ':foo' as './:foo'\n> with your patch?\n\nThat is up for discussion, of course. When discussing a new approach for\nfile mode dependent attributes, I was hoping to get through with\nsymlink:path, and did not. But it was decided that something like\n:symlink:path would be good enough, in the sense of avoiding enough\npossible conflicts. That made me hope that :path would be, too.\n\n(I have not checked for interaction of those two, which are in flight.)\n\nI would think that file names like \":foo\" are problematic on msys\nalready, so in a sense they are no-no already, and free to take as\nspecial notation.\n\nMichael\n"},{"id":"162542","messageId":"4D6CDD2F.5070107@drmicha.warpmail.net","threadId":"26615","inReplyTo":"bc49592f5e524a0d12aa55eeca1c5ca659b6525f.1298974647.git.git@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T11:49:03Z","receivedAt":"2011-03-01T11:49:03Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 01.03.2011 11:21:\n> Introduce a leading ':' as the notation for repo-wide pathspecs.\n> \n> This is in line with our treeish:path notation which defaults to\n> repowide paths.\n> \n> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n> \n> Signed-off-by: Michael J Gruber \n> ---\n> I have not tested this for adverse side effects, only for the intended ones\n> with \"git grep\".\n\nTo follow up:\n\nOf all callers of get_pathspec() (add, checkout, clean, commit, grep,\nls-files, ls-tree, mv, rerere, reset, rm), all work perfectly, except:\n\nls-tree seems to be special not only in this respect.\n\nrerere I'm too dumb to test.\n\nEven things like\n\ngit mv :Makefile Makefile\n\nwork and mv Makefile from the root to your current work dir!\n\nThis may even provide an alternative to switching some defaults to \"repo\nwide\".\n\nMichael\n"},{"id":"162541","messageId":"AANLkTinke05gcQbrDLSUoBUus5gnx+ci5830766d2Jqs@mail.gmail.com","threadId":"26615","inReplyTo":"4D6CD593.2090705@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T11:50:52Z","receivedAt":"2011-03-01T11:50:52Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 6:16 PM, Michael J Gruber\n wrote:\n> Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:13:\n>> 2011/3/1 Michael J Gruber :\n>>> Introduce a leading ':' as the notation for repo-wide pathspecs.\n>>>\n>>> This is in line with our treeish:path notation which defaults to\n>>> repowide paths.\n>>>\n>>> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n>>\n>> If you are going to turn pathspecs into something more complex,\n>> reserve room for future extension. I have negative pathspecs that can\n>> utilize it.\n>>\n>> I take it, from now on people must refer file name ':foo' as './:foo'\n>> with your patch?\n>\n> That is up for discussion, of course. When discussing a new approach for\n> file mode dependent attributes, I was hoping to get through with\n> symlink:path, and did not. But it was decided that something like\n> :symlink:path would be good enough, in the sense of avoiding enough\n> possible conflicts. That made me hope that :path would be, too.\n\nTake me down. I'm going crazy now.\n\nAnother, less cryptic choice, is to make these special notations\nseparate from true pathspecs. For example, instead of \":foo\" we can\nsay \"--root foo\". get_pathspec() and friends can be updated to remove\n--root and rewrite the next pathspec. Extensibility is obvious.\nProblems are plenty:\n\n - may be confused with command line options without \"--\" as separator\n(\"-:\" on the other hand is not, but looks weird)\n - '-' is not a reserved letter, the same as ':'\n - ...\n\n> (I have not checked for interaction of those two, which are in flight.)\n>\n> I would think that file names like \":foo\" are problematic on msys\n> already, so in a sense they are no-no already, and free to take as\n> special notation.\n\nBack to what I'm writing above, '-' may be chosen over ':' even\nwithout separation because UNIXers are trained that '-' is usually the\nbeginning of something special, I suppose most of us would go with\n./-blah for file names.\n-- \nDuy\n"},{"id":"162543","messageId":"4D6CDF20.3020701@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTinke05gcQbrDLSUoBUus5gnx+ci5830766d2Jqs@mail.gmail.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T11:57:20Z","receivedAt":"2011-03-01T11:57:20Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:50:\n> On Tue, Mar 1, 2011 at 6:16 PM, Michael J Gruber\n> wrote:\n>> Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:13:\n>>> 2011/3/1 Michael J Gruber :\n>>>> Introduce a leading ':' as the notation for repo-wide pathspecs.\n>>>>\n>>>> This is in line with our treeish:path notation which defaults to\n>>>> repowide paths.\n>>>>\n>>>> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n>>>\n>>> If you are going to turn pathspecs into something more complex,\n>>> reserve room for future extension. I have negative pathspecs that can\n>>> utilize it.\n>>>\n>>> I take it, from now on people must refer file name ':foo' as './:foo'\n>>> with your patch?\n>>\n>> That is up for discussion, of course. When discussing a new approach for\n>> file mode dependent attributes, I was hoping to get through with\n>> symlink:path, and did not. But it was decided that something like\n>> :symlink:path would be good enough, in the sense of avoiding enough\n>> possible conflicts. That made me hope that :path would be, too.\n> \n> Take me down. I'm going crazy now.\n\nWhat is crazy about that?\n\nHEAD:path is repo wide already\n\n:path is also, after this patch\n\nNote that when you have a file named :foo now, it can already be\nmistaken as the blob at \"foo\" in the index (or HEAD) already, in places\nwhere rev:path makes sense. So you would need quotation before my patch.\n\n> Another, less cryptic choice, is to make these special notations\n> separate from true pathspecs. For example, instead of \":foo\" we can\n> say \"--root foo\". get_pathspec() and friends can be updated to remove\n> --root and rewrite the next pathspec. Extensibility is obvious.\n\nOnly that some commands have \"--root\" as an option, and even if not,\nit's just too much to type.\n\n> Problems are plenty:\n> \n> - may be confused with command line options without \"--\" as separator\n> (\"-:\" on the other hand is not, but looks weird)\n> - '-' is not a reserved letter, the same as ':'\n> - ...\n> \n>> (I have not checked for interaction of those two, which are in flight.)\n>>\n>> I would think that file names like \":foo\" are problematic on msys\n>> already, so in a sense they are no-no already, and free to take as\n>> special notation.\n> \n> Back to what I'm writing above, '-' may be chosen over ':' even\n> without separation because UNIXers are trained that '-' is usually the\n> beginning of something special, I suppose most of us would go with\n> ./-blah for file names.\n\nIf \":\" is crazy which is in line with our current notation, then how do\nyou call \"-\"? \"-\" is\n\n- a short option identifier\n- a negation (attributes)\n- a notation for stdin\n\nMichael\n"},{"id":"162544","messageId":"AANLkTikzSsBZ757p4gnwsUrGNmRKHsxrqXeqPKyLihjT@mail.gmail.com","threadId":"26615","inReplyTo":"4D6CDF20.3020701@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-01T12:08:28Z","receivedAt":"2011-03-01T12:08:28Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 6:57 PM, Michael J Gruber\n wrote:\n> HEAD:path is repo wide already\n>\n> :path is also, after this patch\n>\n> Note that when you have a file named :foo now, it can already be\n> mistaken as the blob at \"foo\" in the index (or HEAD) already, in places\n> where rev:path makes sense. So you would need quotation before my patch.\n\nNo. ':foo' as a reference to 'foo' in index is a SHA1-extended syntax\nand I think we try to avoid ambiguation when a sha1-extended syntax\nmay look like a path or vice versa.\n\n>> Another, less cryptic choice, is to make these special notations\n>> separate from true pathspecs. For example, instead of \":foo\" we can\n>> say \"--root foo\". get_pathspec() and friends can be updated to remove\n>> --root and rewrite the next pathspec. Extensibility is obvious.\n>\n> Only that some commands have \"--root\" as an option, and even if not,\n> it's just too much to type.\n\nYes, choose one between cryptic/short and descriptive/long :)\n\n>> Back to what I'm writing above, '-' may be chosen over ':' even\n>> without separation because UNIXers are trained that '-' is usually the\n>> beginning of something special, I suppose most of us would go with\n>> ./-blah for file names.\n>\n> If \":\" is crazy which is in line with our current notation, then how do\n> you call \"-\"? \"-\" is\n>\n> - a short option identifier\n> - a negation (attributes)\n> - a notation for stdin\n\n'-' is crazy, not ':'. Perhaps I'm embracing '-' too much.\n-- \nDuy\n"},{"id":"162545","messageId":"4D6CEF06.6040406@cisco.com","threadId":"26615","inReplyTo":"4D6CDD2F.5070107@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-03-01T13:05:10Z","receivedAt":"2011-03-01T13:05:10Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 03/01/2011 06:49 AM, Michael J Gruber wrote:\n> Michael J Gruber venit, vidit, dixit 01.03.2011 11:21:\n>> Introduce a leading ':' as the notation for repo-wide pathspecs.\n>>\n>> This is in line with our treeish:path notation which defaults to\n>> repowide paths.\n>>\n>> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n\nI like it. Thanks for looking at this.\n\nPhil\n"},{"id":"162551","messageId":"7vsjv6evy4.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"AANLkTikzSsBZ757p4gnwsUrGNmRKHsxrqXeqPKyLihjT@mail.gmail.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-01T14:50:43Z","receivedAt":"2011-03-01T14:50:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> No. ':foo' as a reference to 'foo' in index is a SHA1-extended syntax\n> and I think we try to avoid ambiguation when a sha1-extended syntax\n> may look like a path or vice versa.\n\nVery true.\n\nJust as a thought experiment (I am skeptical about this whole \"this is\nfrom root\" prefix idea to begin with, but I don't want to shoot an idea\ndown prematurely when there may still be untold gems I haven't seen in\nit):\n\n $ git grep -e frotz .../\n\nto abbreviate \"I don't bother to count my ../\" might be an alternative,\nthough.\n\nThe reason I am skeptical about the \"from root prefix\" is because I do not\nsee a way to make it compatible with other meaningful pathspecs.\n\n $ cd Documentation\n $ git grep -e frotz '*.txt'\n\nwould find frotz in all *.txt files in Documentation (and its\nsubdirectories), if the command takes \"relatigve to cwd\".\n\nIt also is very clear that\n\n $ cd Documentation\n $ git grep --full-tree -e frotz '*.txt'\n\nwould find those anywhere, inside or outside Documentation.\n\nOn the other hand, it is natural to expect that\n\n $ git grep -e frotz \".../*.txt\"\n\nshould find *.txt files _only_ at the root level, so it is not as useful as\nthe --full-tree (or --root).\n"},{"id":"162554","messageId":"4D6D0A51.9030701@drmicha.warpmail.net","threadId":"26615","inReplyTo":"7vsjv6evy4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-01T15:01:37Z","receivedAt":"2011-03-01T15:01:37Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 01.03.2011 15:50:\n> Nguyen Thai Ngoc Duy writes:\n> \n>> No. ':foo' as a reference to 'foo' in index is a SHA1-extended syntax\n>> and I think we try to avoid ambiguation when a sha1-extended syntax\n>> may look like a path or vice versa.\n> \n> Very true.\n> \n> Just as a thought experiment (I am skeptical about this whole \"this is\n> from root\" prefix idea to begin with, but I don't want to shoot an idea\n> down prematurely when there may still be untold gems I haven't seen in\n> it):\n> \n> $ git grep -e frotz .../\n> \n> to abbreviate \"I don't bother to count my ../\" might be an alternative,\n> though.\n> \n> The reason I am skeptical about the \"from root prefix\" is because I do not\n> see a way to make it compatible with other meaningful pathspecs.\n> \n> $ cd Documentation\n> $ git grep -e frotz '*.txt'\n> \n> would find frotz in all *.txt files in Documentation (and its\n> subdirectories), if the command takes \"relatigve to cwd\".\n> \n> It also is very clear that\n> \n> $ cd Documentation\n> $ git grep --full-tree -e frotz '*.txt'\n> \n> would find those anywhere, inside or outside Documentation.\n> \n> On the other hand, it is natural to expect that\n> \n> $ git grep -e frotz \".../*.txt\"\n> \n> should find *.txt files _only_ at the root level, so it is not as useful as\n> the --full-tree (or --root).\n\nExactly that is (one of the reasons) why I used something which does not\nlook like \"as many ../ as necessary\" nor like \"/\". With my implementation,\n\ngit grep -e frotz \":*.txt\"\n\nfrom a subdir will grep the exact same files as\n\n(cd $(git rev-parse --cdup) && git grep -e frotz \"*.txt\")\n\nwill (it is --full-tree!), and will output the results relative to the\ncurrent workdir.\n\nNote that we already have to disambiguate between revspecs and pathspecs\nwith -- in several places; that is not different with the new notation,\nand even not more frequent if it is not used.\n\nI have to say I'm really excited about how transparently this works\nacross all kinds of commands, and how suggestive this is with rev:path\nin mind.\n\nAlso, e.g.,\n\ngit grep -e frotz \"*.c\" \":*.h\"\n\nwill look in all C files in the cwd and and all headers everywhere. Just\nthink of the possibilities, and of the usefulness with clean, add,\ncommit, reset,...!\n\nMichael\n"},{"id":"162556","messageId":"4D6D1E07.1080109@cisco.com","threadId":"26615","inReplyTo":"7vsjv6evy4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-03-01T16:25:43Z","receivedAt":"2011-03-01T16:25:43Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 03/01/2011 09:50 AM, Junio C Hamano wrote:\n> The reason I am skeptical about the \"from root prefix\" is because I do not\n> see a way to make it compatible with other meaningful pathspecs.\n>\n> $ cd Documentation\n> $ git grep -e frotz '*.txt'\n>\n> would find frotz in all *.txt files in Documentation (and its\n> subdirectories), if the command takes \"relatigve to cwd\".\n>\n> It also is very clear that\n>\n> $ cd Documentation\n> $ git grep --full-tree -e frotz '*.txt'\n>\n> would find those anywhere, inside or outside Documentation.\n>\n> On the other hand, it is natural to expect that\n>\n> $ git grep -e frotz \".../*.txt\"\n>\n> should find *.txt files _only_ at the root level, so it is not as\nuseful as\n> the --full-tree (or --root).\n\nI don't understand this last statement. I think it implies that it is\nalso natural to expect that\n\n $ git grep -e frotz -- \"../*.txt\"\n\nshould find *.txt files _only_ in the parent directory. But this is not\nthe case. It returns the same search results as\n\n $ ( cd .. ; git grep -e frotz -- \"*.txt\" )\n\nPhil\n"},{"id":"162563","messageId":"AANLkTimFuU1QduAfwred0zu6LdWN2eHo9X+T4=_qfh_C@mail.gmail.com","threadId":"26615","inReplyTo":"7vsjv6evy4.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2011-03-01T18:31:12Z","receivedAt":"2011-03-01T18:31:12Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> On the other hand, it is natural to expect that\n>\n>    $ git grep -e frotz \".../*.txt\"\n>\n> should find *.txt files _only_ at the root level, so it is not as useful as\n> the --full-tree (or --root).\n\nI've often wished Git supported the zsh '**' wildcard to match anything,\nincluding slashes. Here's another case where it would be useful - to\nmatch *.txt everywhere, you'd use \".../**.txt\", and it leaves you the\noption of using \".../*.txt\" if you really want to find *.txt only at the\nroot level. Of course, it may be very difficult to implement...\n\nJames\n"},{"id":"162567","messageId":"7v8vwyejfu.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"3719d9a120eef618d875629662a87e715de55d4e.1298972832.git.git@drmicha.warpmail.net","subject":"Re: [PATCH/RFC 2/2] grep: make --full-tree work with pathspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-01T19:20:53Z","receivedAt":"2011-03-01T19:20:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> When --full-tree is given, make the pathspecs be applied relative to the\n> root. That way, \"git grep --full-tree expr -- *.c\" looks in all C files in\n> the repo.\n\nThis is basically Ok, but I wonder if this has funny interaction with\nrev/path disambiguation. What happens to these two \"git grep\", and what\nshould happen?\n\n\tcd Documentation\n git grep --full-tree index technical\n git grep --full-tree index Documentation/technical\n\nOnce you said --full-tree, \"technical\" does not refer to Documentation/technical\nso the first one should probably say \"technical is not a rev and there is\nno such path\" while the second one should know Documentation/technical/ is\na pathspec, perhaps?\n"},{"id":"162578","messageId":"7v4o7mehl2.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"4D6D0A51.9030701@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-01T20:00:57Z","receivedAt":"2011-03-01T20:00:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Also, e.g.,\n>\n> git grep -e frotz \"*.c\" \":*.h\"\n>\n> will look in all C files in the cwd and and all headers everywhere.\n\nAh, that is cute. I don't know if the syntax is acceptable to the general\npublic, but I do see the beauty in that approach of marking individual\npathspec as \"(the rest is) from root\".\n\nNice.\n"},{"id":"162611","messageId":"AANLkTim2HmBEQv=buRG7-87+c99FnsxXUTQzKy__azfM@mail.gmail.com","threadId":"26615","inReplyTo":"4D6CD593.2090705@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-02T00:12:16Z","receivedAt":"2011-03-02T00:12:16Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 1, 2011 at 6:16 PM, Michael J Gruber\n wrote:\n> Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:13:\n>> 2011/3/1 Michael J Gruber :\n>>> Introduce a leading ':' as the notation for repo-wide pathspecs.\n>>>\n>>> This is in line with our treeish:path notation which defaults to\n>>> repowide paths.\n>>>\n>>> Heck: Even ':./path' works for pathspecs, and I have no clue why!\n>>\n>> If you are going to turn pathspecs into something more complex,\n>> reserve room for future extension. I have negative pathspecs that can\n>> utilize it.\n>>\n>> I take it, from now on people must refer file name ':foo' as './:foo'\n>> with your patch?\n>\n> That is up for discussion, of course. When discussing a new approach for\n> file mode dependent attributes, I was hoping to get through with\n> symlink:path, and did not. But it was decided that something like\n> :symlink:path would be good enough, in the sense of avoiding enough\n> possible conflicts. That made me hope that :path would be, too.\n\nGood morning! I'm saner now. How about :/path? That would reserve\nanything next to ':' except '/'.\n-- \nDuy\n"},{"id":"162631","messageId":"AANLkTi=YHNnuBAF_GitrmMYFK1h_p9JP54hRyj9vWTzc@mail.gmail.com","threadId":"26615","inReplyTo":"4D6D0A51.9030701@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-03-02T12:34:58Z","receivedAt":"2011-03-02T12:34:58Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Mar 1, 2011 at 16:01, Michael J Gruber wrote:\n> I have to say I'm really excited about how transparently this works\n> across all kinds of commands, and how suggestive this is with rev:path\n> in mind.\n\nI like it, especially considering how small the impact on the codebase\nis. The downside is (once again) backwards compatibility though, I\nhaven't heard much on how to address that, other than \"just quote it\"\n(which _I_ think is fine, people with filenames that start with fancy\ncharacters are probably used to quoting them anyway), but what does\nJunio think?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"162634","messageId":"AANLkTimPGxzP+XfX8Ng5U_4UnPWZCFLQ-3rP4oPTE3o+@mail.gmail.com","threadId":"26615","inReplyTo":"AANLkTi=YHNnuBAF_GitrmMYFK1h_p9JP54hRyj9vWTzc@mail.gmail.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-02T12:57:28Z","receivedAt":"2011-03-02T12:57:28Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 2, 2011 at 7:34 PM, Sverre Rabbelier wrote:\n> Heya,\n>\n> On Tue, Mar 1, 2011 at 16:01, Michael J Gruber wrote:\n>> I have to say I'm really excited about how transparently this works\n>> across all kinds of commands, and how suggestive this is with rev:path\n>> in mind.\n>\n> I like it, especially considering how small the impact on the codebase\n> is. The downside is (once again) backwards compatibility though, I\n> haven't heard much on how to address that, other than \"just quote it\"\n> (which _I_ think is fine, people with filenames that start with fancy\n> characters are probably used to quoting them anyway)\n\nYeah. And if this is accepted, the \"git add -u (without dot)\" issue\nmay cool down. I personally don't mind typing \"git add -u :\" (or \"git\nadd -u :/\").\n-- \nDuy\n"},{"id":"162637","messageId":"4D6E4246.5080407@drmicha.warpmail.net","threadId":"26615","inReplyTo":"AANLkTimPGxzP+XfX8Ng5U_4UnPWZCFLQ-3rP4oPTE3o+@mail.gmail.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-02T13:12:38Z","receivedAt":"2011-03-02T13:12:38Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyen Thai Ngoc Duy venit, vidit, dixit 02.03.2011 13:57:\n> On Wed, Mar 2, 2011 at 7:34 PM, Sverre Rabbelier wrote:\n>> Heya,\n>>\n>> On Tue, Mar 1, 2011 at 16:01, Michael J Gruber wrote:\n>>> I have to say I'm really excited about how transparently this works\n>>> across all kinds of commands, and how suggestive this is with rev:path\n>>> in mind.\n>>\n>> I like it, especially considering how small the impact on the codebase\n>> is. The downside is (once again) backwards compatibility though, I\n>> haven't heard much on how to address that, other than \"just quote it\"\n>> (which _I_ think is fine, people with filenames that start with fancy\n>> characters are probably used to quoting them anyway)\n> \n> Yeah. And if this is accepted, the \"git add -u (without dot)\" issue\n> may cool down. I personally don't mind typing \"git add -u :\" (or \"git\n> add -u :/\").\n\nWhy not even \":)\"\n\nSeriously, I'm glad this is gaining support. As for the notation, I\ntried to take several things into account, which is only possible by\ncompromising somewhat on some:\n\n- usability (as short as possible - 1 char optimum, 2 at most)\n\n- suggestiveness, e.g. \":path\" like in \"rev:path\" in line with git\nusage, or \"/path\" in line with unix usage (although this has the wrong\nconnotation of being anchored at root)\n\n- backward compatibility (new code does not misinterpret old notation)\n\n- msysgit compatibility (I think \"/\" has issues)\n\n- disambiguation from other notation (notably rev:path)\n\nI ended up compromising slightly on the last one. Note that this does\nnot introduce additional ambiguities for existing use cases[*], only for\nthe new notation, i.e. commands expecting \"treeish pathspec\" need a\nhelping double dash when they are feed the new :pathspec without a treeish.\n\nMichael\n\n[*] I keep forgetting that some people may have files whose names begin\nwith \":\". They are ambiguous now already with \"treeish pathspec\"\ncommands, but not with \"pathspec\" commands. The latter would change.\n"},{"id":"162652","messageId":"7vhbblcvl7.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"4D6E4246.5080407@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-02T16:53:40Z","receivedAt":"2011-03-02T16:53:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> [*] I keep forgetting that some people may have files whose names begin\n> with \":\". They are ambiguous now already with \"treeish pathspec\"\n> commands, but not with \"pathspec\" commands. The latter would change.\n\nJust to make sure I understand that they have easy workarounds:\n\n - If you have a path foo/:bar, you can say\n\n git log master -- foo/:bar\n\n because ':' signals the magic and gets stripped only when it is at the\n beginning (i.e. not affecting foo/:bar); and\n\n - For :boz at the root level, you can say\n\n git log master -- '\\:boz'\n\n because the backslash in '\\:boz' makes the colon not at the beginning and\n the glob match sees '\\:boz' and then matches '\\:' with literal ':' at the\n beginning of the pathname \":boz\".\n\nIn very old times, git used to work only from the top-level of the working\ntree.\n\nThe way we give an illusion that a command is restricted within the\ncurrent working directory was by learning the \"prefix\" returned by\nsetup_git_directory() while it chdir(2)'s up to the root level of the\nworking tree, and then by limiting the operation to the pathspec given\nfrom the command line (each of whose elements prefixed by \"prefix\" by\ncalling get_pathspec()).\n\nYour ':'-prefix trick will naturally work very well with this arrangement.\nInstead of prefixing the \"prefix\", you would just strip ':' from the front\nfor such a magic pathspec element, and that should be all that is necessary.\n\nThere is a small worry, though. Some codepaths have tricks that take\nadvantage of the knowledge of the current behaviour that the resulting\npathspec elements all refer to subtree under the \"prefix\", and try to\noptimize their tree traversal. I think dir.c:fill_directory()'s use of\ncommon_prefix() is safe (it recomputes what is common based on the result\nof get_pathspec(), not blindly using the original \"prefix\"), but we need\nto make sure there isn't a codepath that blindly believes that the\noriginal \"prefix\" defines the extent of the operation. Anything that\nunderstands \"../\" to step outside the cwd should be already safe, so I\nhopefully am being worried too much.\n\nEarlier, the list consensus was that if we were to aim for uniformity, we\nshould make everything relative to the root of the working tree when there\nis no pathspec by default, because you can always give a single '.' to\nrestrict the extent of the operation to the cwd, but you cannot extend the\nextent of the operation without tediously counting \"../\". Would this ':'\ntrick affect that argument? If a command is relative to the cwd with no\npathspec, you can now give a single ':' to affect the whole tree.\n\nAs I wrote in my response to Jeff in\n\n http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133874\n\nI always thought that it would be the best solution that makes the choice\nof the default irrelevant, and this \":\" trick certainly feels like this is\nthat solution (I also think having a good default matters).\n\nAnd we can start thinking about deprecating --full-tree option, no? I\nlike that, too ;-).\n"},{"id":"162654","messageId":"4D6E7EF0.5040106@drmicha.warpmail.net","threadId":"26615","inReplyTo":"7vhbblcvl7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-02T17:31:28Z","receivedAt":"2011-03-02T17:31:28Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 02.03.2011 17:53:\n> Michael J Gruber writes:\n> \n>> [*] I keep forgetting that some people may have files whose names begin\n>> with \":\". They are ambiguous now already with \"treeish pathspec\"\n>> commands, but not with \"pathspec\" commands. The latter would change.\n> \n> Just to make sure I understand that they have easy workarounds:\n> \n> - If you have a path foo/:bar, you can say\n> \n> git log master -- foo/:bar\n> \n> because ':' signals the magic and gets stripped only when it is at the\n> beginning (i.e. not affecting foo/:bar); and\n\nYes.\n\n> \n> - For :boz at the root level, you can say\n> \n> git log master -- '\\:boz'\n> \n> because the backslash in '\\:boz' makes the colon not at the beginning and\n> the glob match sees '\\:boz' and then matches '\\:' with literal ':' at the\n> beginning of the pathname \":boz\".\n\nYes. Due to the shell escaping, a shorter way is\n\ngit log master -- ::boz\n\n:)\n\n> \n> In very old times, git used to work only from the top-level of the working\n> tree.\n> \n> The way we give an illusion that a command is restricted within the\n> current working directory was by learning the \"prefix\" returned by\n> setup_git_directory() while it chdir(2)'s up to the root level of the\n> working tree, and then by limiting the operation to the pathspec given\n> from the command line (each of whose elements prefixed by \"prefix\" by\n> calling get_pathspec()).\n> \n> Your ':'-prefix trick will naturally work very well with this arrangement.\n> Instead of prefixing the \"prefix\", you would just strip ':' from the front\n> for such a magic pathspec element, and that should be all that is necessary.\n\nand pretend prefix == NULL, exactly.\n\n> \n> There is a small worry, though. Some codepaths have tricks that take\n> advantage of the knowledge of the current behaviour that the resulting\n> pathspec elements all refer to subtree under the \"prefix\", and try to\n> optimize their tree traversal. I think dir.c:fill_directory()'s use of\n> common_prefix() is safe (it recomputes what is common based on the result\n> of get_pathspec(), not blindly using the original \"prefix\"), but we need\n> to make sure there isn't a codepath that blindly believes that the\n> original \"prefix\" defines the extent of the operation. Anything that\n> understands \"../\" to step outside the cwd should be already safe, so I\n> hopefully am being worried too much.\n\nExcept for rerere, I've tried all callers, and all work. ls-tree is a\nbit strange, but that was true already for rev:path. I think it's OK if\nls-tree does not grok this, but I'll have another look.\n\n> \n> Earlier, the list consensus was that if we were to aim for uniformity, we\n> should make everything relative to the root of the working tree when there\n> is no pathspec by default, because you can always give a single '.' to\n> restrict the extent of the operation to the cwd, but you cannot extend the\n> extent of the operation without tediously counting \"../\".\n\nHadn't we decided there were exceptions (e.g. grep), and there weren't\nthat many suggested changes (to repo-wide) left?\n\n> Would this ':'\n> trick affect that argument? If a command is relative to the cwd with no\n> pathspec, you can now give a single ':' to affect the whole tree.\n\nIn my view yes. I would even say: If we don't change every single\ncommand to repo-wide default there is no need to change (and break\nthings) if we have an easy one-character way of saying \"repo-wide\".\n\n> \n> As I wrote in my response to Jeff in\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133874\n> \n> I always thought that it would be the best solution that makes the choice\n> of the default irrelevant, and this \":\" trick certainly feels like this is\n> that solution (I also think having a good default matters).\n> \n> And we can start thinking about deprecating --full-tree option, no? I\n> like that, too ;-).\n> \n\n:)\n\nMichael\n"},{"id":"162696","messageId":"buo4o7kc4ce.fsf@dhlpc061.dev.necel.com","threadId":"26615","inReplyTo":"4D6E7EF0.5040106@drmicha.warpmail.net","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-03-03T02:42:09Z","receivedAt":"2011-03-03T02:42:09Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Michael J Gruber writes:\n>> Would this ':'\n>> trick affect that argument? If a command is relative to the cwd with no\n>> pathspec, you can now give a single ':' to affect the whole tree.\n>\n> In my view yes. I would even say: If we don't change every single\n> command to repo-wide default there is no need to change (and break\n> things) if we have an easy one-character way of saying \"repo-wide\".\n\n... except, of course that the current state is still confusingly\ninconsistent. Even if \":\" is available, and even if somebody knows\nabout it, they won't use it unless they know they have to because people\nare lazy, particularly when typing at the command-line.\n\nThere will _still_ be tons of times when people don't realize they're in\na subdirectory, and so need \":\", or don't realize that command X doesn't\nfollow the majority of commands in using the \"no args = root relative\"\nbehavior. So the current state of things is still somewhat dangerous\nfor users.\n\nSomething like \":\" would be a great feature for scripting though.\n\n-Miles\n\n-- \nDiscriminate, v.i. To note the particulars in which one person or thing is,\nif possible, more objectionable than another.\n"},{"id":"162697","messageId":"4D6F0E89.4020200@cisco.com","threadId":"26615","inReplyTo":"7vhbblcvl7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-03-03T03:44:09Z","receivedAt":"2011-03-03T03:44:09Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 03/02/2011 11:53 AM, Junio C Hamano wrote:\n> Michael J Gruber writes:\n>> [*] I keep forgetting that some people may have files whose names begin\n>> with \":\". They are ambiguous now already with \"treeish pathspec\"\n>> commands, but not with \"pathspec\" commands. The latter would change.\n> Just to make sure I understand that they have easy workarounds:\n>\n> - If you have a path foo/:bar, you can say\n>\n> git log master -- foo/:bar\n>\n> because ':' signals the magic and gets stripped only when it is at the\n> beginning (i.e. not affecting foo/:bar); and\n>\n> - For :boz at the root level, you can say\n>\n> git log master -- '\\:boz'\n>\n> because the backslash in '\\:boz' makes the colon not at the beginning and\n> the glob match sees '\\:boz' and then matches '\\:' with literal ':' at the\n> beginning of the pathname \":boz\".\n\nEasy workaround, maybe, but still a potential problem for unsuspecting\nscripts.\n\n - I think this fails in a directory with :foo.c\n\n git log master -- *.c\n\n\n - Would this work, though?\n\n git log master -- \"*.c\"\n\nPhil\n"},{"id":"162700","messageId":"4D6F1035.1040902@cisco.com","threadId":"26615","inReplyTo":"AANLkTim2HmBEQv=buRG7-87+c99FnsxXUTQzKy__azfM@mail.gmail.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-03-03T03:51:17Z","receivedAt":"2011-03-03T03:51:17Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 03/01/2011 07:12 PM, Nguyen Thai Ngoc Duy wrote:\n> On Tue, Mar 1, 2011 at 6:16 PM, Michael J Gruber\n> wrote:\n>> Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:13:\n>>> If you are going to turn pathspecs into something more complex,\n>>> reserve room for future extension. I have negative pathspecs that can\n>>> utilize it.\n>>>\n>>> I take it, from now on people must refer file name ':foo' as './:foo'\n>>> with your patch?\n>> That is up for discussion, of course. When discussing a new approach for\n>> file mode dependent attributes, I was hoping to get through with\n>> symlink:path, and did not. But it was decided that something like\n>> :symlink:path would be good enough, in the sense of avoiding enough\n>> possible conflicts. That made me hope that :path would be, too.\n> Good morning! I'm saner now. How about :/path? That would reserve\n> anything next to ':' except '/'.\n\nI like this. The only 'failure' that comes to mind is something like\n\n git log -- */*.c\n\nwhen there's a subdirectory named ':'. \n\nPhil\n"},{"id":"162701","messageId":"7vy64w97yi.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"buo4o7kc4ce.fsf@dhlpc061.dev.necel.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-03T03:52:21Z","receivedAt":"2011-03-03T03:52:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> Michael J Gruber writes:\n>>> Would this ':'\n>>> trick affect that argument? If a command is relative to the cwd with no\n>>> pathspec, you can now give a single ':' to affect the whole tree.\n>>\n>> In my view yes. I would even say: If we don't change every single\n>> command to repo-wide default there is no need to change (and break\n>> things) if we have an easy one-character way of saying \"repo-wide\".\n>\n> ... except, of course that the current state is still confusingly\n> inconsistent....\n\nYou should know that we are already in violent agreement, if you re-read\nmy message where I say \"a good default matters\".\n"},{"id":"162708","messageId":"4D6F4F32.60108@drmicha.warpmail.net","threadId":"26615","inReplyTo":"4D6F0E89.4020200@cisco.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-03T08:20:02Z","receivedAt":"2011-03-03T08:20:02Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Phil Hord venit, vidit, dixit 03.03.2011 04:44:\n> On 03/02/2011 11:53 AM, Junio C Hamano wrote:\n>> Michael J Gruber writes:\n>>> [*] I keep forgetting that some people may have files whose names begin\n>>> with \":\". They are ambiguous now already with \"treeish pathspec\"\n>>> commands, but not with \"pathspec\" commands. The latter would change.\n>> Just to make sure I understand that they have easy workarounds:\n>>\n>> - If you have a path foo/:bar, you can say\n>>\n>> git log master -- foo/:bar\n>>\n>> because ':' signals the magic and gets stripped only when it is at the\n>> beginning (i.e. not affecting foo/:bar); and\n>>\n>> - For :boz at the root level, you can say\n>>\n>> git log master -- '\\:boz'\n>>\n>> because the backslash in '\\:boz' makes the colon not at the beginning and\n>> the glob match sees '\\:boz' and then matches '\\:' with literal ':' at the\n>> beginning of the pathname \":boz\".\n> \n> Easy workaround, maybe, but still a potential problem for unsuspecting\n> scripts.\n> \n> - I think this fails in a directory with :foo.c\n> \n> git log master -- *.c\n> \n> \n> - Would this work, though?\n> \n> git log master -- \"*.c\"\n\nI hope you are aware that these two are completely different before my\npatch already, are you?\n\nThe second one will match \":foo.c\" and any other .c-file at cwd in any\ncommit in master (which changes it), of course. No ambiguity here. This\nis almost always what you want.\n\nThe first one would match \":foo.c\" and any other .c file which you\ncurrently have at cwd in your working tree (!), before my patch (unless\nyou don't have any in your wt), and is almost never what you want.\n\nAfter my patch, it would interpret the \":foo.c\" which the shell glob\nexpands to differently. That is exactly the ambiguity that I mentioned.\n\nMichael\n"},{"id":"162709","messageId":"4D6F4F8E.6090905@drmicha.warpmail.net","threadId":"26615","inReplyTo":"4D6F1035.1040902@cisco.com","subject":"Re: [PATCH/alternative/raw and rough] setup.c: denote repo wide pathspecs by ':'","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-03T08:21:34Z","receivedAt":"2011-03-03T08:21:34Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Phil Hord venit, vidit, dixit 03.03.2011 04:51:\n> On 03/01/2011 07:12 PM, Nguyen Thai Ngoc Duy wrote:\n>> On Tue, Mar 1, 2011 at 6:16 PM, Michael J Gruber\n>> wrote:\n>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 01.03.2011 12:13:\n>>>> If you are going to turn pathspecs into something more complex,\n>>>> reserve room for future extension. I have negative pathspecs that can\n>>>> utilize it.\n>>>>\n>>>> I take it, from now on people must refer file name ':foo' as './:foo'\n>>>> with your patch?\n>>> That is up for discussion, of course. When discussing a new approach for\n>>> file mode dependent attributes, I was hoping to get through with\n>>> symlink:path, and did not. But it was decided that something like\n>>> :symlink:path would be good enough, in the sense of avoiding enough\n>>> possible conflicts. That made me hope that :path would be, too.\n>> Good morning! I'm saner now. How about :/path? That would reserve\n>> anything next to ':' except '/'.\n> \n> I like this. The only 'failure' that comes to mind is something like\n> \n> git log -- */*.c\n> \n> when there's a subdirectory named ':'. \n\nmsysgit anyone?\n\nMichael\n"},{"id":"164153","messageId":"1300894353-19386-1-git-send-email-pclouds@gmail.com","threadId":"26615","inReplyTo":"bc49592f5e524a0d12aa55eeca1c5ca659b6525f.1298974647.git.git@drmicha.warpmail.net","subject":"[PATCH] pathspec: reserve some letters after a colon pathspec","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-23T15:32:33Z","receivedAt":"2011-03-23T15:32:33Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Pathspec ':something' means 'something' at top directory. Limit it a\nbit so that ':something' can be reserved for future\nextensions. ':\\something' can be used to achieve\n':something' before this patch.\n\nAll non-alphanumeric chars on the en_US keyboard, except \\ and ., are\ncurrently reserved.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n This is the better, non-whitespace-damaged version. While I mark\n colon_pathspec_type() static, you can export it to use in git-attr.c\n\n setup.c | 31 +++++++++++++++++++++++++++++--\n 1 files changed, 29 insertions(+), 2 deletions(-)\n\ndiff --git a/setup.c b/setup.c\nindex 3bbb01a..684abb5 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -123,6 +123,27 @@ void verify_non_filename(const char *prefix, const char *arg)\n \t \"Use '--' to separate filenames from revisions\", arg);\n }\n \n+static int colon_pathspec_type(const char **pathspec)\n+{\n+\tconst char *reserved = \"~`!@#$%^&*()-_=+[{]}|;:'\\\",<>/?\";\n+\tconst char *s = *pathspec;\n+\tint ret;\n+\n+\tif (*s++ != ':')\n+\t\treturn -1;\n+\tif (*s == '\\\\') {\n+\t\ts++;\n+\t\tret = 0;\n+\t}\n+\telse if (*s && strchr(reserved, *s))\n+\t\tret = -1;\n+\telse\n+\t\tret = 0;\n+\n+\t*pathspec = s;\n+\treturn ret;\n+}\n+\n const char **get_pathspec(const char *prefix, const char **pathspec)\n {\n \tconst char *entry = *pathspec;\n@@ -145,8 +166,14 @@ const char **get_pathspec(const char *prefix, const char **pathspec)\n \tprefixlen = prefix ? strlen(prefix) : 0;\n \twhile (*src) {\n \t\tconst char *p;\n-\t\tif ((*src)[0] == ':')\n-\t\t\tp = prefix_path(NULL, 0, (*src)+1);\n+\n+\t\tif ((*src)[0] == ':') {\n+\t\t\tconst char **s = src;\n+\t\t\tif (colon_pathspec_type(s) != 0)\n+\t\t\t\tdie(\"Pathspec syntax ':%c' is not supported. %s\"\n+\t\t\t\t \"Quote it for literally match.\", (*s)[0], *s);\n+\t\t\tp = prefix_path(NULL, 0, *s);\n+\t\t}\n \t\telse\n \t\t\tp = prefix_path(prefix, prefixlen, *src);\n \t\t*(dst++) = p;\n-- \n1.7.4.74.g639db\n"},{"id":"164171","messageId":"7vvcz9emrn.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"1300894353-19386-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] pathspec: reserve some letters after a colon pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-23T18:04:44Z","receivedAt":"2011-03-23T18:04:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Pathspec ':something' means 'something' at top directory. Limit it a\n> bit so that ':something' can be reserved for future\n> extensions. ':\\something' can be used to achieve\n> ':something' before this patch.\n>\n> All non-alphanumeric chars on the en_US keyboard, except \\ and ., are\n> currently reserved.\n\nWhile I was writing the other message, I really was hoping that people\nwould notice that trying to limit the magic signature (i.e. \"which magic I\nwant\" in my previous message) to a non-alnum letter that cannot easily be\nremembered would be a bad direction. A set of short mnemonic is fine, but\nwe probably should prepare the syntax framework to reserve spelled out\nmagic names for readability.\n\nHere is a weather-baloon. I will use colon below as the magic introducer,\nas I don't care very deeply about the choice of it.\n\n - \"^:([^\\w\\d]+)(.*)$\", that is \"a magic introducer followed by a sequence\n of non-alnum followed by the remainder\" means that the part that is\n given to the matching engine is $2, and each gibberish character in $1\n determines what magic is requested when the matching engine does its\n work. Among the gibberish that can be in $1, we currently would want\n to support:\n\n . '/' denotes that $2 is relative to root of the working tree, i.e. do\n not add 'prefix' to it at the left.\n\n . '!' denotes that the matching with $2 should not honor globbing.\n\n e.g.\n\n \":/*lib/**/foo.h\", if '*' denoted recursive glob support for '**/' to\n mean \"zero-or-more levels of any directory\" [*1*], it would find any\n foo.h in a directory 'lib' or its subdirectory that is found in\n anywhere in the working tree.\n\n - \"^:((?:[-a-z]+)(?:,[-a-z+]+)*):(.*)$\", that is \"a magic introducer,\n followed by one or more alpha-string separated with comma, followed\n by a magic terminator, and the remainder\" means that the remainder is\n what is given to the matching engine, and the alpha-strings spell out\n the name of the magic. We currently would want to support:\n\n . 'full-tree' means exactly the same as '/' mnemonic above.\n . 'noglob' means exactly the same as '!' mnemonic.\n\n e.g.\n\n \":full-tree,recursive-glob:lib/**/foo.h\" would be how you fully spell\n the above example in the mnemonic section [*2*].\n\n\n[Footnote]\n\n*1* \"man zshexpn\" and look for \"Recursive Globbing\".\n\n*2* It would be \"/full-tree,recursive-glob/lib/**/foo.h\" if the magic\nintroducer were '/', which might be easier to the eye.\n"},{"id":"164206","messageId":"4D8AEF9B.9050001@drmicha.warpmail.net","threadId":"26615","inReplyTo":"7vvcz9emrn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] pathspec: reserve some letters after a colon pathspec","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-03-24T07:15:39Z","receivedAt":"2011-03-24T07:15:39Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 23.03.2011 19:04:\n> Nguyễn Thái Ngọc Duy writes:\n> \n>> Pathspec ':something' means 'something' at top directory. Limit it a\n>> bit so that ':something' can be reserved for future\n>> extensions. ':\\something' can be used to achieve\n>> ':something' before this patch.\n>>\n>> All non-alphanumeric chars on the en_US keyboard, except \\ and ., are\n>> currently reserved.\n> \n> While I was writing the other message, I really was hoping that people\n> would notice that trying to limit the magic signature (i.e. \"which magic I\n> want\" in my previous message) to a non-alnum letter that cannot easily be\n> remembered would be a bad direction. A set of short mnemonic is fine, but\n> we probably should prepare the syntax framework to reserve spelled out\n> magic names for readability.\n> \n> Here is a weather-baloon. I will use colon below as the magic introducer,\n> as I don't care very deeply about the choice of it.\n> \n> - \"^:([^\\w\\d]+)(.*)$\", that is \"a magic introducer followed by a sequence\n> of non-alnum followed by the remainder\" means that the part that is\n> given to the matching engine is $2, and each gibberish character in $1\n> determines what magic is requested when the matching engine does its\n> work. Among the gibberish that can be in $1, we currently would want\n> to support:\n> \n> . '/' denotes that $2 is relative to root of the working tree, i.e. do\n> not add 'prefix' to it at the left.\n> \n> . '!' denotes that the matching with $2 should not honor globbing.\n> \n> e.g.\n> \n> \":/*lib/**/foo.h\", if '*' denoted recursive glob support for '**/' to\n> mean \"zero-or-more levels of any directory\" [*1*], it would find any\n> foo.h in a directory 'lib' or its subdirectory that is found in\n> anywhere in the working tree.\n> \n> - \"^:((?:[-a-z]+)(?:,[-a-z+]+)*):(.*)$\", that is \"a magic introducer,\n> followed by one or more alpha-string separated with comma, followed\n> by a magic terminator, and the remainder\" means that the remainder is\n> what is given to the matching engine, and the alpha-strings spell out\n> the name of the magic. We currently would want to support:\n> \n> . 'full-tree' means exactly the same as '/' mnemonic above.\n> . 'noglob' means exactly the same as '!' mnemonic.\n> \n> e.g.\n> \n> \":full-tree,recursive-glob:lib/**/foo.h\" would be how you fully spell\n> the above example in the mnemonic section [*2*].\n\nI like this a lot, especially the fact that we would have descriptive\nlong names as well as short versions for a subset! Two remarks:\n\n:(symlink|submodule|directory|file): would fit into that scheme (for use\nin .gitattributes), though I'm not sure we want that for general\npathspecs. We probably want textconv applied to :file: only by default,\nattributes to match with :file only?\n\nWe already have \":./cdwfile\" as in \"commit:./cwdfile\", and this looks\nlike a preexisting instance, although it is not (\"commit:\" gets stripped\nand \"./cwdfile\" is the pathspec). People will probably try something\nlike \"commit:/rootfile\", and we may or may not want to support this.\nThat particular one is easy, but \"commit:full-tree:name\" has a defined\nmeaning now...\n\nMichael\n"},{"id":"164213","messageId":"AANLkTinjdi3+qcQxcBYj8SdQgbZYP=KiLwxM3Vq0c1Er@mail.gmail.com","threadId":"26615","inReplyTo":"4D8AEF9B.9050001@drmicha.warpmail.net","subject":"Re: [PATCH] pathspec: reserve some letters after a colon pathspec","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-03-24T07:49:20Z","receivedAt":"2011-03-24T07:49:20Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2011/3/24 Michael J Gruber :\n>> Here is a weather-baloon.  I will use colon below as the magic introducer,\n>> as I don't care very deeply about the choice of it.\n>>\n>>  - \"^:([^\\w\\d]+)(.*)$\", that is \"a magic introducer followed by a sequence\n>>    of non-alnum followed by the remainder\" means that the part that is\n>>    given to the matching engine is $2, and each gibberish character in $1\n>>    determines what magic is requested when the matching engine does its\n>>    work.  Among the gibberish that can be in $1, we currently would want\n>>    to support:\n>>\n>>     . '/' denotes that $2 is relative to root of the working tree, i.e. do\n>>       not add 'prefix' to it at the left.\n>>\n>>     . '!' denotes that the matching with $2 should not honor globbing.\n>>\n\nAnd maybe:\n\n . ':' to reach the superproject if user's inside a subproject. So\n'::/foo' means foo at superproject while ':/foo' means foo in the\ncurrent project, both at root.\n\n>>  ...\n>\n> I like this a lot, especially the fact that we would have descriptive\n> long names as well as short versions for a subset!\n\nI'll leave it to you to come up with something we can test :)\n\n> Two remarks:\n>\n> :(symlink|submodule|directory|file): would fit into that scheme (for use\n> in .gitattributes), though I'm not sure we want that for general\n> pathspecs. We probably want textconv applied to :file: only by default,\n> attributes to match with :file only?\n\nIt does not hurt to have generic support for everything. 'git ls-files\n-- :executable:' would be nice, though I'm not sure if I will ever use\nit.\n\n> We already have \":./cdwfile\" as in \"commit:./cwdfile\", and this looks\n> like a preexisting instance, although it is not (\"commit:\" gets stripped\n> and \"./cwdfile\" is the pathspec). People will probably try something\n> like \"commit:/rootfile\", and we may or may not want to support this.\n> That particular one is easy, but \"commit:full-tree:name\" has a defined\n> meaning now...\n\nI think we should leave this one out. It's to address a single path.\nIf you bring full pathspec support to it, a pathspec may resolve to\nmultiple paths, which is unwanted. If people want pathspecs, they can\ndo \"git cmd commit -- pathspecs\" most of the time.\n-- \nDuy\n"},{"id":"164216","messageId":"7vsjud9bso.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"AANLkTinjdi3+qcQxcBYj8SdQgbZYP=KiLwxM3Vq0c1Er@mail.gmail.com","subject":"Re: [PATCH] pathspec: reserve some letters after a colon pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-24T08:12:55Z","receivedAt":"2011-03-24T08:12:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> And maybe:\n>\n> . ':' to reach the superproject if user's inside a subproject. So\n> '::/foo' means foo at superproject while ':/foo' means foo in the\n> current project, both at root.\n\nA magic with that meaning may be fine (or may be not---I don't care too\nmuch about \"because we could\" at this point), but if you are going to use\n':' as the magic introducer, you cannot use ':' as one of the magic\nsignatures, as it would make it ambiguous when you said '::'. Did you\nwrite a long-form with 0 spelled-out magic (perhaps to defeat some other\nfuture settings like --option or config)? Or did you mean that magic\nsignature?\n"},{"id":"164230","messageId":"7vei5wa84e.fsf@alter.siamese.dyndns.org","threadId":"26615","inReplyTo":"4D8AEF9B.9050001@drmicha.warpmail.net","subject":"Re: [PATCH] pathspec: reserve some letters after a colon pathspec","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-03-24T14:46:57Z","receivedAt":"2011-03-24T14:46:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 23.03.2011 19:04:\n> ...\n>> Here is a weather-baloon. I will use colon below as the magic introducer,\n>> as I don't care very deeply about the choice of it.\n>> \n>> - \"^:([^\\w\\d]+)(.*)$\", that is \"a magic introducer followed by a sequence\n>> of non-alnum followed by the remainder\" means that the part that is\n>> given to the matching engine is $2, and each gibberish character in $1\n>> determines what magic is requested when the matching engine does its\n>> work. Among the gibberish that can be in $1, we currently would want\n>> to support:\n>> \n>> . '/' denotes that $2 is relative to root of the working tree, i.e. do\n>> not add 'prefix' to it at the left.\n>> \n>> . '!' denotes that the matching with $2 should not honor globbing.\n>> \n>> e.g.\n>> \n>> \":/*lib/**/foo.h\", if '*' denoted recursive glob support for '**/' to\n>> mean \"zero-or-more levels of any directory\" [*1*], it would find any\n>> foo.h in a directory 'lib' or its subdirectory that is found in\n>> anywhere in the working tree.\n>> \n>> - \"^:((?:[-a-z]+)(?:,[-a-z+]+)*):(.*)$\", that is \"a magic introducer,\n>> followed by one or more alpha-string separated with comma, followed\n>> by a magic terminator, and the remainder\" means that the remainder is\n>> what is given to the matching engine, and the alpha-strings spell out\n>> the name of the magic. We currently would want to support:\n>> \n>> . 'full-tree' means exactly the same as '/' mnemonic above.\n>> . 'noglob' means exactly the same as '!' mnemonic.\n>> \n>> e.g.\n>> \n>> \":full-tree,recursive-glob:lib/**/foo.h\" would be how you fully spell\n>> the above example in the mnemonic section [*2*].\n>\n> I like this a lot, especially the fact that we would have descriptive\n> long names as well as short versions for a subset! Two remarks:\n>\n> :(symlink|submodule|directory|file): would fit into that scheme (for use\n> in .gitattributes), though I'm not sure we want that for general\n> pathspecs.\n\nI do not offhand think it is a good idea. While traversing history the\npathspec matcher often does not have the mode information extracted from\nthe tree object in the codepath it inspects the name, so it would be very\ncostly, I don't think it would particularly be useful, and pathspec is\nabout names and not about types.\n\nA magic that says \"please match case insensitively\", so that we do not\nhave to write \"git log -- '[Rr][Ee][Aa][Dd][Mm][Ee]'\" would be very\nuseful. Perhaps \"gibberish\" is not a good long term solution after all,\nas a natural short-hand for that magic would be a single letter 'i'\nsomewhere, similar to (?i) in pcre.\n"}]}