{"thread":{"id":"25993","subject":"[PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","startedAt":"2010-12-08T14:58:37Z","lastAt":"2010-12-10T23:36:22Z","messageCount":32,"participants":["Nguyễn Thái Ngọc Duy","Thiago Farina","Jonathan Nieder","Jakub Narebski","Junio C Hamano","Nguyen Thai Ngoc Duy","Kevin Ballard","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"157602","messageId":"1291820319-12455-1-git-send-email-pclouds@gmail.com","threadId":"25993","inReplyTo":null,"subject":"[PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-08T14:58:37Z","receivedAt":"2010-12-08T14:58:37Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Let's start off from where the previous discussion [1] stopped. People\nseem to agree ref^{/regex} is a good choice. But we have not come to\nconclusion how to specify the count yet. Possible suggestions are\n\n - ref^{/foo}2\n - ref^{2/foo}\n - ref^{:2/foo}\n - ref^{2nd/foo}\n\nFor whatever syntax chosen, :/ should benefit too. I notice that :/!\nis reserved for future use. Perhaps :/!2/regex is not too cryptic?\n\nI'd also like to do case-insensitive regex, by the way. :/!2i/regex\nlooks a bit ugly.\n\n[1] http://mid.gmane.org/9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org\n\nNguyễn Thái Ngọc Duy (2):\n get_sha1_oneline: allow to input commit_list\n get_sha1: support ref^{/regex} syntax\n\n Documentation/revisions.txt | 7 ++++++\n sha1_name.c | 45 ++++++++++++++++++++++++++++++++----------\n 2 files changed, 41 insertions(+), 11 deletions(-)\n\n-- \n1.7.3.2.316.gda8b3\n"},{"id":"157603","messageId":"1291820319-12455-2-git-send-email-pclouds@gmail.com","threadId":"25993","inReplyTo":"1291820319-12455-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 1/2] get_sha1_oneline: allow to input commit_list","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-08T14:58:38Z","receivedAt":"2010-12-08T14:58:38Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n sha1_name.c | 19 ++++++++++++-------\n 1 files changed, 12 insertions(+), 7 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex 2c3a5fb..f4ccdc5 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -686,13 +686,14 @@ static int handle_one_ref(const char *path,\n \tif (object->type != OBJ_COMMIT)\n \t\treturn 0;\n \tinsert_by_date((struct commit *)object, list);\n-\tobject->flags |= ONELINE_SEEN;\n \treturn 0;\n }\n \n-static int get_sha1_oneline(const char *prefix, unsigned char *sha1)\n+static int get_sha1_oneline(const char *prefix,\n+\t\t\t unsigned char *sha1,\n+\t\t\t struct commit_list *list_)\n {\n-\tstruct commit_list *list = NULL, *backup = NULL, *l;\n+\tstruct commit_list *list = list_, *backup = NULL, *l;\n \tint retval = -1;\n \tchar *temp_commit_buffer = NULL;\n \tregex_t regex;\n@@ -706,9 +707,12 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)\n \tif (regcomp(®ex, prefix, REG_EXTENDED))\n \t\tdie(\"Invalid search pattern: %s\", prefix);\n \n-\tfor_each_ref(handle_one_ref, &list);\n-\tfor (l = list; l; l = l->next)\n+\tif (!list)\n+\t\tfor_each_ref(handle_one_ref, &list);\n+\tfor (l = list; l; l = l->next) {\n \t\tcommit_list_insert(l->item, &backup);\n+\t\tl->item->object.flags |= ONELINE_SEEN;\n+\t}\n \twhile (list) {\n \t\tchar *p;\n \t\tstruct commit *commit;\n@@ -737,7 +741,8 @@ static int get_sha1_oneline(const char *prefix, unsigned char *sha1)\n \t}\n \tregfree(®ex);\n \tfree(temp_commit_buffer);\n-\tfree_commit_list(list);\n+\tif (!list_)\n+\t\tfree_commit_list(list);\n \tfor (l = backup; l; l = l->next)\n \t\tclear_commit_marks(l->item, ONELINE_SEEN);\n \treturn retval;\n@@ -1090,7 +1095,7 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,\n \t\tint pos;\n \t\tif (namelen > 2 && name[1] == '/')\n \t\t\t/* don't need mode for commit */\n-\t\t\treturn get_sha1_oneline(name + 2, sha1);\n+\t\t\treturn get_sha1_oneline(name + 2, sha1, NULL);\n \t\tif (namelen < 3 ||\n \t\t name[2] != ':' ||\n \t\t name[1] < '0' || '3' < name[1])\n-- \n1.7.3.2.316.gda8b3\n"},{"id":"157604","messageId":"1291820319-12455-3-git-send-email-pclouds@gmail.com","threadId":"25993","inReplyTo":"1291820319-12455-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 2/2] get_sha1: support ref^{/regex} syntax","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-08T14:58:39Z","receivedAt":"2010-12-08T14:58:39Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"This works like :/ syntax, but only limited to one ref.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Documentation/revisions.txt | 7 +++++++\n sha1_name.c | 26 ++++++++++++++++++++++----\n 2 files changed, 29 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/revisions.txt b/Documentation/revisions.txt\nindex 3d4b79c..fbe6245 100644\n--- a/Documentation/revisions.txt\n+++ b/Documentation/revisions.txt\n@@ -106,6 +106,13 @@ the `$GIT_DIR/refs` directory or from the `$GIT_DIR/packed-refs` file.\n and dereference the tag recursively until a non-tag object is\n found.\n \n+* A suffix '{caret}' to a revision parameter followed by a brace\n+ pair that contains a text led by a slash (e.g. `HEAD^{/fix nasty bug}`):\n+ this names a commit whose commit message matches the specified\n+ regular expression. This name returns the youngest matching commit\n+ which is reachable from the dereferenced commit. The leading '!'\n+ in the text is treated especially like in `:/` syntax below.\n+\n * A colon, followed by a slash, followed by a text (e.g. `:/fix nasty bug`): this names\n a commit whose commit message matches the specified regular expression.\n This name returns the youngest matching commit which is\ndiff --git a/sha1_name.c b/sha1_name.c\nindex f4ccdc5..00e52b0 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -527,6 +527,7 @@ struct object *peel_to_type(const char *name, int namelen,\n \t}\n }\n \n+static int get_sha1_oneline(const char *, unsigned char *, struct commit_list *);\n static int peel_onion(const char *name, int len, unsigned char *sha1)\n {\n \tunsigned char outer[20];\n@@ -562,6 +563,11 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n \t\texpected_type = OBJ_BLOB;\n \telse if (sp[0] == '}')\n \t\texpected_type = OBJ_NONE;\n+\telse if (sp[0] == '/') {\n+\t\tif (sp[1] == '}')\n+\t\t\treturn -1;\n+\t\texpected_type = OBJ_COMMIT;\n+\t}\n \telse\n \t\treturn -1;\n \n@@ -584,11 +590,23 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n \t\t * barf.\n \t\t */\n \t\to = peel_to_type(name, len, o, expected_type);\n-\t\tif (o) {\n-\t\t\thashcpy(sha1, o->sha1);\n-\t\t\treturn 0;\n+\t\tif (!o)\n+\t\t\treturn -1;\n+\n+\t\thashcpy(sha1, o->sha1);\n+\t\tif (sp[0] == '/') { /* ^{/foo} */\n+\t\t\tstruct commit_list *list = NULL;\n+\t\t\tchar *prefix;\n+\t\t\tint ret;\n+\n+\t\t\tcommit_list_insert((struct commit *)o, &list);\n+\t\t\tprefix = xstrndup(sp + 1, name + len - 1 - (sp + 1));\n+\t\t\tret = get_sha1_oneline(prefix, sha1, list);\n+\t\t\tfree(prefix);\n+\t\t\tfree_commit_list(list);\n+\t\t\treturn ret;\n \t\t}\n-\t\treturn -1;\n+\t\treturn 0;\n \t}\n \treturn 0;\n }\n-- \n1.7.3.2.316.gda8b3\n"},{"id":"157605","messageId":"AANLkTim1AN9TWiAFem4U0V7GuU45QfLEbNk_-k6rdtyQ@mail.gmail.com","threadId":"25993","inReplyTo":"1291820319-12455-2-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 1/2] get_sha1_oneline: allow to input commit_list","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2010-12-08T15:11:09Z","receivedAt":"2010-12-08T15:11:09Z","isPatch":true,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"2010/12/8 Nguyễn Thái Ngọc Duy :\n>\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> -static int get_sha1_oneline(const char *prefix, unsigned char *sha1)\n> +static int get_sha1_oneline(const char *prefix,\n> +                           unsigned char *sha1,\n> +                           struct commit_list *list_)\n>  {\n\nmicronit: can we have a better name for |list_|, the suffix _ is very\nugly and uncommon :(\n"},{"id":"157616","messageId":"20101208180605.GD5687@burratino","threadId":"25993","inReplyTo":"1291820319-12455-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-08T18:06:05Z","receivedAt":"2010-12-08T18:06:05Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyễn Thái Ngọc Duy wrote:\n\n> Let's start off from where the previous discussion [1] stopped. People\n> seem to agree ref^{/regex} is a good choice. But we have not come to\n> conclusion how to specify the count yet. Possible suggestions are\n>\n> - ref^{/foo}2\n> - ref^{2/foo}\n> - ref^{:2/foo}\n> - ref^{2nd/foo}\n\nHow about\n\n\tref^{/foo}^^{/foo}\n\n?\n"},{"id":"157621","messageId":"201012082047.44022.jnareb@gmail.com","threadId":"25993","inReplyTo":"1291820319-12455-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-08T19:47:42Z","receivedAt":"2010-12-08T19:47:42Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Wed, 8 Dec 2010, Nguyễn Thái Ngọc Duy wrote:\n\n> Let's start off from where the previous discussion [1] stopped. People\n> seem to agree ref^{/regex} is a good choice. But we have not come to\n> conclusion how to specify the count yet. Possible suggestions are\n> \n> - ref^{/foo}2\n> - ref^{2/foo}\n> - ref^{:2/foo}\n> - ref^{2nd/foo}\n> \n> For whatever syntax chosen, :/ should benefit too. I notice that :/!\n> is reserved for future use. Perhaps :/!2/regex is not too cryptic?\n\nI wonder if it would be possible to make :/ (which looks a bit\nlike searching the index) to be an alias to --all^{/}...\n\nOr if we can make ^{/} to act on revision range specified by\nearlier commits, so for example foo..bar^{/} would work.\n\n> I'd also like to do case-insensitive regex, by the way. :/!2i/regex\n> looks a bit ugly.\n\nThe '2nd' idea came from Perl 6 regexp / grammars, see for example\nhttps://github.com/perlpilot/perl6-docs/blob/master/intro/p6-regex-intro.pod\n\n There are two other modifiers for matching a pattern some number of times\n or only matching, say, the third time we see a pattern in a string. These\n modifiers are a little strange in that their short-hand forms consist of\n a number followed by some text:\n\n modifier short-hand meaning\n :x() :1x,:4x,:12x match some number of times\n :nth() :1st,:2nd,:3rd,:4th match only the Nth occurance\n\n Here are some examples to illustrate these modifiers:\n\n $_ = \"foo bar baz blat\";\n m :3x/ a / # matches the \"a\" characters in each word\n m :nth(3)/ \\w+ / # matches \"baz\"\n\nSo it could be e.g. 'foo^{:2nd/}' (note that there is no trailing\n/ closing regexp, i.e. it is not 'foo^{:2nd//}').\n\nSo if we chose this, why don't we follow Perl 6 rule of combining modifiers\nhttp://perlcabal.org/syn/S05.html#Modifiers, so it would be\n\n foo^{:2nd:i/}\n\nor\n\n foo^{:i:nth(2)/}\n\n\nAs to :/! form: isn't it reserved for non-match? If not, then\nperhaps\n\n :/!2nd:i/\n\n> [1] http://mid.gmane.org/9D675671-693D-4B59-AF2A-0EFE4C537362@sb.org\n> \n> Nguyễn Thái Ngọc Duy (2):\n> get_sha1_oneline: allow to input commit_list\n> get_sha1: support ref^{/regex} syntax\n> \n> Documentation/revisions.txt | 7 ++++++\n> sha1_name.c | 45 ++++++++++++++++++++++++++++++++----------\n> 2 files changed, 41 insertions(+), 11 deletions(-)\n\nThank you for working on this.\n-- \nJakub Narebski\nPoland\n"},{"id":"157622","messageId":"201012082051.09730.jnareb@gmail.com","threadId":"25993","inReplyTo":"20101208180605.GD5687@burratino","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-08T19:51:08Z","receivedAt":"2010-12-08T19:51:08Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:\n> Nguyễn Thái Ngọc Duy wrote:\n> \n> > Let's start off from where the previous discussion [1] stopped. People\n> > seem to agree ref^{/regex} is a good choice. But we have not come to\n> > conclusion how to specify the count yet. Possible suggestions are\n> >\n> > - ref^{/foo}2\n> > - ref^{2/foo}\n> > - ref^{:2/foo}\n> > - ref^{2nd/foo}\n> \n> How about\n> \n> \tref^{/foo}^^{/foo}\n> \n> ?\n\nI'll assume that there is invisible \";)\" emoticon here.\n\n\nFirst, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only\nfirst parent.\n\nSecond, consider ref^{:nth(10)/foo} in your workaround...\n\n;-)\n\n-- \nJakub Narebski\nPoland\n"},{"id":"157626","messageId":"20101208204014.GA6289@burratino","threadId":"25993","inReplyTo":"201012082047.44022.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-08T20:40:14Z","receivedAt":"2010-12-08T20:40:14Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jakub Narebski wrote:\n\n> So if we chose this, why don't we follow Perl 6 rule of combining modifiers\n> http://perlcabal.org/syn/S05.html#Modifiers, so it would be\n>\n> foo^{:2nd:i/}\n>\n> or\n>\n> foo^{:i:nth(2)/}\n\nVery nice.\n"},{"id":"157638","messageId":"7vvd33j2um.fsf@alter.siamese.dyndns.org","threadId":"25993","inReplyTo":"1291820319-12455-3-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 2/2] get_sha1: support ref^{/regex} syntax","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-08T22:50:57Z","receivedAt":"2010-12-08T22:50:57Z","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> diff --git a/sha1_name.c b/sha1_name.c\n> index f4ccdc5..00e52b0 100644\n> --- a/sha1_name.c\n> +++ b/sha1_name.c\n> @@ -562,6 +563,11 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n> \t\texpected_type = OBJ_BLOB;\n> \telse if (sp[0] == '}')\n> \t\texpected_type = OBJ_NONE;\n> +\telse if (sp[0] == '/') {\n> +\t\tif (sp[1] == '}')\n> +\t\t\treturn -1;\n\nWhy? $commit^{/} may be a no-op but I do not see a strong reason to\nwaste extra two lines to forbid it.\n\n> @@ -584,11 +590,23 @@ static int peel_onion(const char *name, int len, unsigned char *sha1)\n> \t\t * barf.\n> \t\t */\n> \t\to = peel_to_type(name, len, o, expected_type);\n> -\t\tif (o) {\n> -\t\t\thashcpy(sha1, o->sha1);\n> -\t\t\treturn 0;\n> +\t\tif (!o)\n> +\t\t\treturn -1;\n\nI can see you are trying to reduce nesting of\n\n if (o) {\n\t\tdo true thing\n return 0\n\t}\n return -1;\n\nbut then we should apply the same to outer \"if (!expected_type) ... else\",\ntoo, to unnest the \"else\" clause by returning from the true branch of that\n\"if\".\n"},{"id":"157654","messageId":"AANLkTi=AyCxn=dcKQQmT0_6Oc36AX6XDA4Dhhk7WLSN0@mail.gmail.com","threadId":"25993","inReplyTo":"201012082047.44022.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-09T00:30:45Z","receivedAt":"2010-12-09T00:30:45Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2010/12/9 Jakub Narebski :\n> I wonder if it would be possible to make :/ (which looks a bit\n> like searching the index) to be an alias to --all^{/}...\n\nIt looks a bit strange to my eyes to merge normal option name with\nrevision syntax. But I think it's possible. Do we allow branch/tag\nname with leading '-'?\n\n> Or if we can make ^{/} to act on revision range specified by\n> earlier commits, so for example foo..bar^{/} would work.\n\nThere is another case: branch/tag selection. Instead of looking in all\nrefs, people may want to look only in nd/* branches. My branches are\nalmost flat, so I don't find any use. But someone might. And we can\nsolve the \"all branches\" case above with simply \"*\". The exact syntax,\nI don't know.\n\n> As to :/! form: isn't it reserved for non-match?\n\nIt is reserved and not attached with any meaning.\n\n> Thank you for working on this.\n\nYou're welcome. I needed to look for my branches in pu and was tired\nof copy/paste.\n-- \nDuy\n"},{"id":"157655","messageId":"201012090144.19858.jnareb@gmail.com","threadId":"25993","inReplyTo":"AANLkTi=AyCxn=dcKQQmT0_6Oc36AX6XDA4Dhhk7WLSN0@mail.gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-09T00:44:18Z","receivedAt":"2010-12-09T00:44:18Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n> 2010/12/9 Jakub Narebski :\n\n> > I wonder if it would be possible to make :/ (which looks a bit\n> > like searching the index) to be an alias to --all^{/}...\n> \n> It looks a bit strange to my eyes to merge normal option name with\n> revision syntax. But I think it's possible. Do we allow branch/tag\n> name with leading '-'?\n\nWell, with below proposal it would simply be\n\n --all ^{/}\n \n> > Or if we can make ^{/} to act on revision range specified by\n> > earlier commits, so for example foo..bar^{/} would work.\n> \n> There is another case: branch/tag selection. Instead of looking in all\n> refs, people may want to look only in nd/* branches. My branches are\n> almost flat, so I don't find any use. But someone might. And we can\n> solve the \"all branches\" case above with simply \"*\". The exact syntax,\n> I don't know.\n\n --glob=heads/nd/ ^{/}\n\nSimilarly to the --all case.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"157656","messageId":"AANLkTimU6Bhx-2XsZ45_7BmT9fo9MpK8TJWB3zZ=j-i7@mail.gmail.com","threadId":"25993","inReplyTo":"201012082051.09730.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-09T01:28:07Z","receivedAt":"2010-12-09T01:28:07Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 9, 2010 at 2:51 AM, Jakub Narebski wrote:\n> Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:\n>> Nguyễn Thái Ngọc Duy wrote:\n>>\n>> > Let's start off from where the previous discussion [1] stopped. People\n>> > seem to agree ref^{/regex} is a good choice. But we have not come to\n>> > conclusion how to specify the count yet. Possible suggestions are\n>> >\n>> >  - ref^{/foo}2\n>> >  - ref^{2/foo}\n>> >  - ref^{:2/foo}\n>> >  - ref^{2nd/foo}\n>>\n>> How about\n>>\n>>       ref^{/foo}^^{/foo}\n>>\n>> ?\n>\n> I'll assume that there is invisible \";)\" emoticon here.\n>\n>\n> First, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only\n> first parent.\n>\n> Second, consider ref^{:nth(10)/foo} in your workaround...\n\nMaybe we should generalize this to apply to all operators. Currently\nfoo~3 is expanded to foo^^^. How about ~~X (or xN) denote repeat the\nlast operator N times? For example, HEAD^2x3 => HEAD^2^2^2,\nHEAD^{/foo}x3 => HEAD^{/foo}^{/foo}^{/foo}.\n-- \nDuy\n"},{"id":"157659","messageId":"AANLkTin1SjEzBnLd-HK9fANShLezAKHAOai9MyF-cuoT@mail.gmail.com","threadId":"25993","inReplyTo":"201012090144.19858.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-09T01:42:51Z","receivedAt":"2010-12-09T01:42:51Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski wrote:\n> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n>> 2010/12/9 Jakub Narebski :\n>\n>> > I wonder if it would be possible to make :/ (which looks a bit\n>> > like searching the index) to be an alias to --all^{/}...\n>>\n>> It looks a bit strange to my eyes to merge normal option name with\n>> revision syntax. But I think it's possible. Do we allow branch/tag\n>> name with leading '-'?\n>\n> Well, with below proposal it would simply be\n>\n>  --all ^{/}\n\nThis hardly works with range and may conflict with \"--all\" being\nalready used by some commands.\n\nI think we can move '/' out of {}, the space between '/' and '{' can\nbe used for optional parameters: ^/{foo}.\n-- \nDuy\n"},{"id":"157660","messageId":"C1C51028-60B5-46EE-B172-1A9330FBBB8A@sb.org","threadId":"25993","inReplyTo":"AANLkTin1SjEzBnLd-HK9fANShLezAKHAOai9MyF-cuoT@mail.gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-12-09T01:46:16Z","receivedAt":"2010-12-09T01:46:16Z","isPatch":true,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Dec 8, 2010, at 5:42 PM, Nguyen Thai Ngoc Duy wrote:\n\n> On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski wrote:\n>> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n>>> 2010/12/9 Jakub Narebski :\n>> \n>>>> I wonder if it would be possible to make :/ (which looks a bit\n>>>> like searching the index) to be an alias to --all^{/}...\n>>> \n>>> It looks a bit strange to my eyes to merge normal option name with\n>>> revision syntax. But I think it's possible. Do we allow branch/tag\n>>> name with leading '-'?\n>> \n>> Well, with below proposal it would simply be\n>> \n>> --all ^{/}\n> \n> This hardly works with range and may conflict with \"--all\" being\n> already used by some commands.\n> \n> I think we can move '/' out of {}, the space between '/' and '{' can\n> be used for optional parameters: ^/{foo}\n\nI thought ^{} was going to be an arbitrary grouping operator, capable of\nembedding any other modifier, but primarily only useful for regex. This\nchange explicitly makes it an alternative regex syntax.\n\n-Kevin Ballard\n"},{"id":"157661","messageId":"201012090254.24999.jnareb@gmail.com","threadId":"25993","inReplyTo":"AANLkTimU6Bhx-2XsZ45_7BmT9fo9MpK8TJWB3zZ=j-i7@mail.gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-09T01:54:23Z","receivedAt":"2010-12-09T01:54:23Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> On Thu, Dec 9, 2010 at 2:51 AM, Jakub Narebski wrote:\n>> Dnia środa 8. grudnia 2010 19:06, Jonathan Nieder napisał:\n>>> Nguyễn Thái Ngọc Duy wrote:\n>>>\n>>>> Let's start off from where the previous discussion [1] stopped. People\n>>>> seem to agree ref^{/regex} is a good choice. But we have not come to\n>>>> conclusion how to specify the count yet. Possible suggestions are\n>>>>\n>>>>  - ref^{/foo}2\n>>>>  - ref^{2/foo}\n>>>>  - ref^{:2/foo}\n>>>>  - ref^{2nd/foo}\n>>>\n>>> How about\n>>>\n>>>       ref^{/foo}^^{/foo}\n>>>\n>>> ?\n>>\n>> I'll assume that there is invisible \";)\" emoticon here.\n>>\n>>\n>> First, it would be ref^{/foo}^@^{/foo}, otherwise you would follow only\n>> first parent.\n>>\n>> Second, consider ref^{:nth(10)/foo} in your workaround...\n> \n> Maybe we should generalize this to apply to all operators. Currently\n> foo~3 is expanded to foo^^^. How about ~~X (or xN) denote repeat the\n> last operator N times? For example, HEAD^2x3 => HEAD^2^2^2,\n> HEAD^{/foo}x3 => HEAD^{/foo}^{/foo}^{/foo}.\n\nUnless you allow grouping, it wouldn't help in the case of ^{/foo},\nbecause ^{/foo} is idempotent. HEAD^{/foo} finds first commit that\ncontains \"foo\", and HEAD^{/foo}^{/foo} finds first commit containing\n\"foo\" starting from *and including* first commit from HEAD containing\n\"foo\" - which is HEAD^{/foo}\n\n HEAD^{/foo}^{/foo} === HEAD^{/foo}\n\nYou would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\nmeans really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"157662","messageId":"20101209015926.GA31119@burratino","threadId":"25993","inReplyTo":"201012090254.24999.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-09T01:59:26Z","receivedAt":"2010-12-09T01:59:26Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jakub Narebski wrote:\n\n> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\n> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n\nThat said, does ^2x500 really do something meaningful that a person\nwould ever need? I like the\n\n\t^{:nth(3)/foo}\n\nsyntax because perl6 supports m:nth(3)/foo/, suggesting a menu of\nalready-defined modifiers to implement when they prove useful, known\nalready to a certain subset of the audience and proven useful already\nin a different context.\n"},{"id":"157663","messageId":"192758EC-4276-445D-B1D5-284073D5AB32@sb.org","threadId":"25993","inReplyTo":"20101209015926.GA31119@burratino","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-12-09T02:02:40Z","receivedAt":"2010-12-09T02:02:40Z","isPatch":true,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Dec 8, 2010, at 5:59 PM, Jonathan Nieder wrote:\n\n> Jakub Narebski wrote:\n> \n>> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\n>> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n> \n> That said, does ^2x500 really do something meaningful that a person\n> would ever need? I like the\n> \n> \t^{:nth(3)/foo}\n> \n> syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of\n> already-defined modifiers to implement when they prove useful, known\n> already to a certain subset of the audience and proven useful already\n> in a different context.\n\nI like the ^{:nth(3)/foo} syntax as well. Though I'm not familiar with Perl 6,\nthis does have the benefit of being fairly obvious to the reader as to what it\nmeans.\n\n-Kevin Ballard"},{"id":"157664","messageId":"AANLkTikOehig7LjpUC=b6iSjGnuF=TsZmipWDfQB7AW6@mail.gmail.com","threadId":"25993","inReplyTo":"192758EC-4276-445D-B1D5-284073D5AB32@sb.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-09T02:06:52Z","receivedAt":"2010-12-09T02:06:52Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 9, 2010 at 9:02 AM, Kevin Ballard wrote:\n> On Dec 8, 2010, at 5:59 PM, Jonathan Nieder wrote:\n>\n>> Jakub Narebski wrote:\n>>\n>>> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\n>>> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n>>\n>> That said, does ^2x500 really do something meaningful that a person\n>> would ever need?  I like the\n>>\n>>       ^{:nth(3)/foo}\n>>\n>> syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of\n>> already-defined modifiers to implement when they prove useful, known\n>> already to a certain subset of the audience and proven useful already\n>> in a different context.\n>\n> I like the ^{:nth(3)/foo} syntax as well. Though I'm not familiar with Perl 6,\n> this does have the benefit of being fairly obvious to the reader as to what it\n> means.\n\nOK so :nth(3)/foo for all branches?\n-- \nDuy\n"},{"id":"157665","messageId":"20101209021117.GB31119@burratino","threadId":"25993","inReplyTo":"AANLkTikOehig7LjpUC=b6iSjGnuF=TsZmipWDfQB7AW6@mail.gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-09T02:11:17Z","receivedAt":"2010-12-09T02:11:17Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> OK so :nth(3)/foo for all branches?\n\nThat steals namespace from \"the path 'nth(3)/foo' in the index\". But\nis \"the third instance of foo in all branches\" something that needs to\nbe possible to say? Branches do not have a well defined order,\nanyway. A command to list all commits with \"foo\" in the subject\nlike\n\n\tgit log --oneline --grep-subject=foo\n\nsounds more useful (assuming --grep=foo yields too many false\npositives).\n"},{"id":"157668","messageId":"7vaakfil1m.fsf@alter.siamese.dyndns.org","threadId":"25993","inReplyTo":"201012082051.09730.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-09T05:15:33Z","receivedAt":"2010-12-09T05:15:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Second, consider ref^{:nth(10)/foo} in your workaround...\n\nFeels way over-engineered to me.\n"},{"id":"157672","messageId":"7vsjy7h3db.fsf@alter.siamese.dyndns.org","threadId":"25993","inReplyTo":"20101209015926.GA31119@burratino","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-09T06:22:40Z","receivedAt":"2010-12-09T06:22:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Jakub Narebski wrote:\n>\n>> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\n>> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n>\n> That said, does ^2x500 really do something meaningful that a person\n> would ever need? I like the\n>\n> \t^{:nth(3)/foo}\n>\n> syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of\n> already-defined modifiers to implement when they prove useful,...\n\nCan you explain what the colon in \"$commit^{:nth(3)/foo}\" is doing? \n\nAre we declaring anything that begins with ':' is a magic inside ^{...}\nconstruct?\n\nI do not think nth($n) without specifying where to start (iow, what the\ncurrent \":/foo\" implementation does but with \"three levels deep\") makes\nany sense, but because the main point of your argument is that we can have\nmodifies other than nth($n) that may make sense in such a context, I would\nwant to make sure anything we come up with is extensible to that syntax.\n\nOn the \"starting from any ref\" front, I think \"!\" (as in \":/!some magic\")\nwas the introducer we reserved for such a magic some time ago, so perhaps\non the \"starting from this commit\" side, \"^{!magic/foo}\" may be more\nappropriate?\n"},{"id":"157681","messageId":"201012091238.15685.jnareb@gmail.com","threadId":"25993","inReplyTo":"7vsjy7h3db.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-09T11:38:14Z","receivedAt":"2010-12-09T11:38:14Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 9 Dec 2010, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>> Jakub Narebski wrote:\n>>\n>>> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\n>>> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n>>\n>> That said, does ^2x500 really do something meaningful that a person\n>> would ever need? I like the\n>>\n>> \t^{:nth(3)/foo}\n>>\n>> syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of\n>> already-defined modifiers to implement when they prove useful,...\n> \n> Can you explain what the colon in \"$commit^{:nth(3)/foo}\" is doing? \n> \n> Are we declaring anything that begins with ':' is a magic inside ^{...}\n> construct?\n\nThe idea is to follow Perl 6 rule of combining modifiers \"Every modifier\nmust start with its own colon.\"\n http://perlcabal.org/syn/S05.html#Modifiers\n\nThis allow for easy combining modifiers without introducing special rules,\nfor example ^{:g:i/foo} would return all matches (:g == :global) instead\nof only the first, ignoring case (:i == :ignorecase).\n \n> I do not think nth($n) without specifying where to start (iow, what the\n> current \":/foo\" implementation does but with \"three levels deep\") makes\n> any sense, but because the main point of your argument is that we can have\n> modifies other than nth($n) that may make sense in such a context, I would\n> want to make sure anything we come up with is extensible to that syntax.\n\nHmmm... I haven't thought about it. I guess that ^{:nth(N)/foo} should\nreturn Nth element in the list that ^{:g/foo} / --grep=foo would return.\n\nThis way one could use\n\n $ git log pu@{1}..pu --merges --grep=\"Merge branch 'nd/\"\n\nto find all new Nguyen contributions in 'pu', and\n\n $ git log pu..pu^{:2nd/Merge branch 'nd/}^2\n\nto view 2nd (2nd == nth(2)) such branch on the list.\n\n> \n> On the \"starting from any ref\" front, I think \"!\" (as in \":/!some magic\")\n> was the introducer we reserved for such a magic some time ago, so perhaps\n> on the \"starting from this commit\" side, \"^{!magic/foo}\" may be more\n> appropriate?\n\nI'd like to deprecate \":/foo\" in favor of \"--all ^{/foo}\", or even special\ncase it to \"^{/foo}\" (if not attached to ref, ^{(:)*/}\nacts on positive revs replacing them).\n\nBut ^{/foo} might be overengineered...\n-- \nJakub Narebski\nPoland\n"},{"id":"157682","messageId":"201012091243.44824.jnareb@gmail.com","threadId":"25993","inReplyTo":"AANLkTin1SjEzBnLd-HK9fANShLezAKHAOai9MyF-cuoT@mail.gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-09T11:43:43Z","receivedAt":"2010-12-09T11:43:43Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n> On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski wrote:\n>> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n>>> 2010/12/9 Jakub Narebski :\n>>\n>>>> I wonder if it would be possible to make :/ (which looks a bit\n>>>> like searching the index) to be an alias to --all^{/}...\n>>>\n>>> It looks a bit strange to my eyes to merge normal option name with\n>>> revision syntax. But I think it's possible. Do we allow branch/tag\n>>> name with leading '-'?\n>>\n>> Well, with below proposal it would simply be\n>>\n>>  --all ^{/}\n> \n> This hardly works with range and may conflict with \"--all\" being\n> already used by some commands.\n\nIt is '--all' like in \"git log --all\".\n \nThe proposed semantics for ^{/foo} (i.e. not attached to revision)\nwould be that it acts on all positive revs on the left of it, replacing\nthem. But that might be not easy to do, and it feels a bit \noverengineered.\n\n> I think we can move '/' out of {}, the space between '/' and '{' can\n> be used for optional parameters: ^/{foo}.\n\nDo you mean using e.g. ^/:i{foo} for :ignorecase, instead of ^{:i/foo}\nor ^{i/foo}?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"157683","messageId":"AANLkTikc_ROE5uiEOnwOi64zV8w5X17U7vjsGsfuu=gN@mail.gmail.com","threadId":"25993","inReplyTo":"201012091243.44824.jnareb@gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-09T11:53:35Z","receivedAt":"2010-12-09T11:53:35Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 9, 2010 at 6:43 PM, Jakub Narebski wrote:\n> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n>> On Thu, Dec 9, 2010 at 7:44 AM, Jakub Narebski wrote:\n>>> On Thu, 9 Dec 2010, Nguyen Thai Ngoc Duy wrote:\n>>>> 2010/12/9 Jakub Narebski :\n>>>\n>>>>> I wonder if it would be possible to make :/ (which looks a bit\n>>>>> like searching the index) to be an alias to --all^{/}...\n>>>>\n>>>> It looks a bit strange to my eyes to merge normal option name with\n>>>> revision syntax. But I think it's possible. Do we allow branch/tag\n>>>> name with leading '-'?\n>>>\n>>> Well, with below proposal it would simply be\n>>>\n>>>  --all ^{/}\n>>\n>> This hardly works with range and may conflict with \"--all\" being\n>> already used by some commands.\n>\n> It is '--all' like in \"git log --all\".\n>\n> The proposed semantics for ^{/foo} (i.e. not attached to revision)\n> would be that it acts on all positive revs on the left of it, replacing\n> them.  But that might be not easy to do, and it feels a bit\n> overengineered.\n\nYes, maybe.\n\n>> I think we can move '/' out of {}, the space between '/' and '{' can\n>> be used for optional parameters: ^/{foo}.\n>\n> Do you mean using e.g. ^/:i{foo} for :ignorecase, instead of ^{:i/foo}\n> or ^{i/foo}?\n\nYes. I find \"^/\" easier to read than \"^{/\". But \"^{/\" is more\nconsistent to the rest.\n-- \nDuy\n"},{"id":"157817","messageId":"AANLkTimg4Cy83gjzgC3fwg+t=B57b6gzOE98p-=2AR+K@mail.gmail.com","threadId":"25993","inReplyTo":"7vsjy7h3db.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-10T13:25:25Z","receivedAt":"2010-12-10T13:25:25Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 9, 2010 at 1:22 PM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> Jakub Narebski wrote:\n>>\n>>> You would need HEAD{^{/foo}^@}x3, or use special rule that HEAD^{/foo}x2\n>>> means really HEAD^{/foo}^@^{/foo}, with ^@ used to join them.\n>>\n>> That said, does ^2x500 really do something meaningful that a person\n>> would ever need?  I like the\n>>\n>>       ^{:nth(3)/foo}\n>>\n>> syntax because perl6 supports m:nth(3)/foo/, suggesting a menu of\n>> already-defined modifiers to implement when they prove useful,...\n>\n> Can you explain what the colon in \"$commit^{:nth(3)/foo}\" is doing?\n>\n> Are we declaring anything that begins with ':' is a magic inside ^{...}\n> construct?\n>\n> I do not think nth($n) without specifying where to start (iow, what the\n> current \":/foo\" implementation does but with \"three levels deep\") makes\n> any sense, but because the main point of your argument is that we can have\n> modifies other than nth($n) that may make sense in such a context, I would\n> want to make sure anything we come up with is extensible to that syntax.\n\nThere's also another similar operation: note search. I don't think we\nneed to invent another syntax for note search, a modifier for ^{/foo}\nmay be a good choice.\n\n> On the \"starting from any ref\" front, I think \"!\" (as in \":/!some magic\")\n> was the introducer we reserved for such a magic some time ago, so perhaps\n> on the \"starting from this commit\" side, \"^{!magic/foo}\" may be more\n> appropriate?\n\nCan we use ! modifier for other ^{} too? What I have in mind is how to\nsay ^{commit} that has two parents. Or even better, \"search from the\ngiven tip for a commit that has two parents and the commit message\nmatches 'foo'\". Hmm.. too complex. Perhaps \"^{grep: }\"\nthat pulls the whole git-grep functionality in.\n-- \nDuy\n"},{"id":"157836","messageId":"20101210190332.GA6210@burratino","threadId":"25993","inReplyTo":"AANLkTimg4Cy83gjzgC3fwg+t=B57b6gzOE98p-=2AR+K@mail.gmail.com","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-10T19:03:32Z","receivedAt":"2010-12-10T19:03:32Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> Can we use ! modifier for other ^{} too? What I have in mind is how to\n> say ^{commit} that has two parents. Or even better, \"search from the\n> given tip for a commit that has two parents and the commit message\n> matches 'foo'\". Hmm.. too complex. Perhaps \"^{grep: }\"\n> that pulls the whole git-grep functionality in.\n\nMy thoughts, in no particular order:\n\n - '!' can be a pain in the neck to supply on the bash command line.\n Single quotes and backslash quoting work while double quotes do\n not, unless 'set +H' has been run. But that's not a huge deal and\n arguably it's a bash misfeature.\n\n - What is the intended use for this family of modifiers? I sort\n of understand ^{:i/... } for people that forget what case they\n have used, but why the :nth and others?\n\n - Why do we have to carve out the namespace right away, anyway? If\n we just ^{/... } for the ordinary \"start here\" search, that leaves\n room for anything after the { other than \"/\" and a few\n fixed strings like \"upstream\", \"tree\", etc, right? It might be\n easier to anticipate what syntax will be useful when there is\n functionality to go with it.\n"},{"id":"157838","messageId":"201012102026.42363.jnareb@gmail.com","threadId":"25993","inReplyTo":"20101210190332.GA6210@burratino","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-12-10T19:26:40Z","receivedAt":"2010-12-10T19:26:40Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 10 Dec 2010 20:03, Jonathan Nieder wrote:\n> Nguyen Thai Ngoc Duy wrote:\n> \n> > Can we use ! modifier for other ^{} too? What I have in mind is how to\n> > say ^{commit} that has two parents. Or even better, \"search from the\n> > given tip for a commit that has two parents and the commit message\n> > matches 'foo'\". Hmm.. too complex. Perhaps \"^{grep: }\"\n> > that pulls the whole git-grep functionality in.\n> \n> My thoughts, in no particular order:\n> \n> - '!' can be a pain in the neck to supply on the bash command line.\n> Single quotes and backslash quoting work while double quotes do\n> not, unless 'set +H' has been run. But that's not a huge deal and\n> arguably it's a bash misfeature.\n> \n> - What is the intended use for this family of modifiers? I sort\n> of understand ^{:i/... } for people that forget what case they\n> have used, but why the :nth and others?\n\n* :nth(N) and :g, to show nth match and all matches, respectively; might\n be not necessary as it impinges a bit on --grep= domain\n* :N / :notesRef to search also through attached notes\n\nIf we was possible, perhaps also\n\n* :b / :basechar to ignore accents and other marks (according to commit\n encoding).\n\n\n-- \nJakub Narebski\nPoland\n"},{"id":"157846","messageId":"66D6F30D-4707-4057-BB46-57B2DF01F479@sb.org","threadId":"25993","inReplyTo":"20101210190332.GA6210@burratino","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-12-10T21:21:15Z","receivedAt":"2010-12-10T21:21:15Z","isPatch":true,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Dec 10, 2010, at 11:03 AM, Jonathan Nieder wrote:\n\n> - What is the intended use for this family of modifiers? I sort\n> of understand ^{:i/... } for people that forget what case they\n> have used, but why the :nth and others?\n\nIn my particular case, I was glancing through the logs, and I wanted to grab\nthe second branch that someone else had made that was merged into pu. I would\nhave loved to be able to run something like\n\n git merge origin/pu^{:nth(2)/nd/}\n\nWhile we're speaking of modifiers, could we use one that says \"only search\nthe first parent hierarchy\", e.g. something equivalent to git log's --first-parent\nflag?\n\n-Kevin Ballard"},{"id":"157847","messageId":"20101210213017.GA14256@sigill.intra.peff.net","threadId":"25993","inReplyTo":"66D6F30D-4707-4057-BB46-57B2DF01F479@sb.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-12-10T21:30:17Z","receivedAt":"2010-12-10T21:30:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 10, 2010 at 01:21:15PM -0800, Kevin Ballard wrote:\n\n> On Dec 10, 2010, at 11:03 AM, Jonathan Nieder wrote:\n> \n> > - What is the intended use for this family of modifiers? I sort\n> > of understand ^{:i/... } for people that forget what case they\n> > have used, but why the :nth and others?\n> \n> In my particular case, I was glancing through the logs, and I wanted to grab\n> the second branch that someone else had made that was merged into pu. I would\n> have loved to be able to run something like\n> \n> git merge origin/pu^{:nth(2)/nd/}\n> \n> While we're speaking of modifiers, could we use one that says \"only search\n> the first parent hierarchy\", e.g. something equivalent to git log's --first-parent\n> flag?\n\nAs neat as this modifier syntax is getting, are we perhaps just\nrecreating the wheel?\n\nHow about:\n\n git merge `git rev-list -2 --grep=nd/ origin/pu | tail -1`\n\nfor the nth one, and:\n\n git merge `git rev-list --first-parent -1 --grep=nd/ origin/pu`\n\nfor a first parent search (I will leave combining them as an exercise to\nthe reader).\n\nIt's not that I'm opposed to a handy ref-specifying syntax. I just\nwonder if it is really worth building in all of these obscure scenarios.\n\n-Peff\n"},{"id":"157853","messageId":"7vipz1b4zm.fsf@alter.siamese.dyndns.org","threadId":"25993","inReplyTo":"66D6F30D-4707-4057-BB46-57B2DF01F479@sb.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-10T23:08:45Z","receivedAt":"2010-12-10T23:08:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Ballard writes:\n\n> On Dec 10, 2010, at 11:03 AM, Jonathan Nieder wrote:\n>\n>> - What is the intended use for this family of modifiers? I sort\n>> of understand ^{:i/... } for people that forget what case they\n>> have used, but why the :nth and others?\n>\n> In my particular case, I was glancing through the logs, and I wanted to grab\n> the second branch that someone else had made that was merged into pu. I would\n> have loved to be able to run something like\n>\n> git merge origin/pu^{:nth(2)/nd/}\n>\n> While we're speaking of modifiers, could we use one that says \"only search\n> the first parent hierarchy\", e.g. something equivalent to git log's --first-parent\n> flag?\n\nBoth feels like a very made-up example to me.\n\nThe reason you can so sure that you can to give nth(2) not nth(3) nor\nnth(1) and run \"merge\" in the example is probably because you looked at\nthe output from \"git log --first-parent --oneline origin..origin/pu\", no?\n\n d414638 Merge branch 'rj/msvc-fix' into pu\n e5f5e49 Merge branch 'ak/describe-exact' into pu\n 439932d Merge branch 'jn/svn-fe' into pu\n d60b33b Merge branch 'pd/bash-4-completion' into pu\n 09cbbde Merge branch 'tf/commit-list-prefix' into pu\n 1b2ea00 Merge branch 'mg/cvsimport' into pu\n c6d41f4 Merge branch 'nd/maint-relative' into pu\n 81f395e Merge branch 'ab/i18n' into pu\n 9f5471f Merge branch 'nd/setup' into pu\n 06f74a4 Merge branch 'yd/dir-rename' into pu\n d8a2ec8 Merge branch 'en/object-list-with-pathspec' into pu\n\nAfter looking at this output, do you really want to say \":nth(2)/nd/\"\ninstead of 9f5471f?\n\nTo come up with the \"(2)\" part you need to carefully scan the other lines\nand make sure that there is only one \"nd/\" after what you want, and the\nstring does not appear in an unexpected places.\n"},{"id":"157854","messageId":"64905EED-F368-4D3F-9D2D-C08D9B460D67@sb.org","threadId":"25993","inReplyTo":"7vipz1b4zm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2010-12-10T23:11:56Z","receivedAt":"2010-12-10T23:11:56Z","isPatch":true,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Dec 10, 2010, at 3:08 PM, Junio C Hamano wrote:\n\n> Kevin Ballard writes:\n> \n>> On Dec 10, 2010, at 11:03 AM, Jonathan Nieder wrote:\n>> \n>>> - What is the intended use for this family of modifiers? I sort\n>>> of understand ^{:i/... } for people that forget what case they\n>>> have used, but why the :nth and others?\n>> \n>> In my particular case, I was glancing through the logs, and I wanted to grab\n>> the second branch that someone else had made that was merged into pu. I would\n>> have loved to be able to run something like\n>> \n>> git merge origin/pu^{:nth(2)/nd/}\n>> \n>> While we're speaking of modifiers, could we use one that says \"only search\n>> the first parent hierarchy\", e.g. something equivalent to git log's --first-parent\n>> flag?\n> \n> Both feels like a very made-up example to me.\n\nAnd yet the example I gave is pretty much precisely what prompted me to start\nthis discussion in the first place.\n\n> The reason you can so sure that you can to give nth(2) not nth(3) nor\n> nth(1) and run \"merge\" in the example is probably because you looked at\n> the output from \"git log --first-parent --oneline origin..origin/pu\", no?\n> \n> d414638 Merge branch 'rj/msvc-fix' into pu\n> e5f5e49 Merge branch 'ak/describe-exact' into pu\n> 439932d Merge branch 'jn/svn-fe' into pu\n> d60b33b Merge branch 'pd/bash-4-completion' into pu\n> 09cbbde Merge branch 'tf/commit-list-prefix' into pu\n> 1b2ea00 Merge branch 'mg/cvsimport' into pu\n> c6d41f4 Merge branch 'nd/maint-relative' into pu\n> 81f395e Merge branch 'ab/i18n' into pu\n> 9f5471f Merge branch 'nd/setup' into pu\n> 06f74a4 Merge branch 'yd/dir-rename' into pu\n> d8a2ec8 Merge branch 'en/object-list-with-pathspec' into pu\n> \n> After looking at this output, do you really want to say \":nth(2)/nd/\"\n> instead of 9f5471f?\n\nYep. Doing the latter either requires me to swap over to my mouse, copy the sha1,\nand paste in, or requires me to peer at the sha1 and re-type enough characters.\nIt's a lot easier to just glance at that list, realize the 2nd one is the one I\nwant, and type `git merge :^{nth(2)/nd/}`. It may not necessarily be faster than\nretyping the sha1, but it's a lot less prone to transcription errors.\n\n-Kevin Ballard"},{"id":"157856","messageId":"7v7hfhb3pl.fsf@alter.siamese.dyndns.org","threadId":"25993","inReplyTo":"64905EED-F368-4D3F-9D2D-C08D9B460D67@sb.org","subject":"Re: [PATCH 0/2] [RFD] Using gitrevisions :/search style with other operators","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-10T23:36:22Z","receivedAt":"2010-12-10T23:36:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kevin Ballard writes:\n\n> On Dec 10, 2010, at 3:08 PM, Junio C Hamano wrote:\n> ...\n>> d414638 Merge branch 'rj/msvc-fix' into pu\n>> ...\n>> 1b2ea00 Merge branch 'mg/cvsimport' into pu\n>> c6d41f4 Merge branch 'nd/maint-relative' into pu\n>> 81f395e Merge branch 'ab/i18n' into pu\n>> 9f5471f Merge branch 'nd/setup' into pu\n>> 06f74a4 Merge branch 'yd/dir-rename' into pu\n>> d8a2ec8 Merge branch 'en/object-list-with-pathspec' into pu\n>> \n>> After looking at this output, do you really want to say \":nth(2)/nd/\"\n>> instead of 9f5471f?\n>\n> Yep. Doing the latter either requires me to swap over to my mouse, copy the sha1,\n> and paste in, or requires me to peer at the sha1 and re-type enough characters.\n> It's a lot easier to just glance at that list, realize the 2nd one is the one I\n> want, and type `git merge :^{nth(2)/nd/}`. It may not necessarily be faster than\n> retyping the sha1, but it's a lot less prone to transcription errors.\n\nWhat you said heavily depends on the way in which I give names to the\nbranches, and also on the fact that \"nd/\" happens to be not very common\nprefix at this moment. If the branches were named without nd/ part and\nstill be unique, you would not be arguing for nth(2) at all to begin with.\n\nSo it is dubious that your argument is convincing.\n"}]}