{"thread":{"id":"41083","subject":"[PATCH/RFC v2 0/2] add regex match flags to git describe","startedAt":"2015-12-28T10:30:22Z","lastAt":"2016-01-06T12:23:05Z","messageCount":14,"participants":["Mostyn Bramley-Moore","Junio C Hamano","Duy Nguyen"],"isPatch":true,"patchVersion":2,"patchTotal":2},"messages":[{"id":"275040","messageId":"cover.1451298323.git.mostynb@opera.com","threadId":"41083","inReplyTo":null,"subject":"[PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-28T10:30:22Z","receivedAt":"2015-12-28T10:30:22Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"git describe currently only supports glob matching with the --matches flag.\nIt would be useful to support regular expressions.\n\nFor consistency, this uses the same regex flags as those used by git-grep.\n\nSome old discussion of this as a candidate feature is here, though nobody put\ntogether a patch as far as I can see:\nhttp://comments.gmane.org/gmane.comp.version-control.git/173873\n\n\n-Mostyn.\n\nMostyn Bramley-Moore (2):\n describe: add option to use perl-compatible regexes with --match\n describe: add basic and extended posix regex matching for completeness\n\n Documentation/git-describe.txt | 21 ++++++-\n builtin/describe.c | 131 ++++++++++++++++++++++++++++++++++++++++-\n t/README | 3 +-\n t/t6120-describe.sh | 38 ++++++++++--\n 4 files changed, 184 insertions(+), 9 deletions(-)\n\n-- \n2.5.0\n"},{"id":"275041","messageId":"980902959f83a7f82e6f5eb38f4c3a8bf074c77a.1451298323.git.mostynb@opera.com","threadId":"41083","inReplyTo":"cover.1451298323.git.mostynb@opera.com","subject":"[PATCH/RFC v2 1/2] describe: add option to use perl-compatible regexes with --match","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-28T10:30:23Z","receivedAt":"2015-12-28T10:30:23Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"This allows more flexible pattern matching than the default globs.\n\nSigned-off-by: Mostyn Bramley-Moore \n---\n Documentation/git-describe.txt | 15 +++++--\n builtin/describe.c | 90 +++++++++++++++++++++++++++++++++++++++++-\n t/README | 3 +-\n t/t6120-describe.sh | 24 +++++++++--\n 4 files changed, 123 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex c8f28c8..b8279ec 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -81,9 +81,18 @@ OPTIONS\n \tthat points at object deadbee....).\n \n --match ::\n-\tOnly consider tags matching the given `glob(7)` pattern,\n-\texcluding the \"refs/tags/\" prefix. This can be used to avoid\n-\tleaking private tags from the repository.\n+\tOnly consider tags matching the given pattern, excluding the\n+\t\"refs/tags/\" prefix. This can be used to avoid leaking private\n+\ttags from the repository. The pattern type can be chosen by\n+\tspecifying --glob or --perl-regexp.\n+\n+--glob::\n+\tUse `glob(7)` patterns with --match, this is the default.\n+\n+-P::\n+--perl-regexp::\n+\tUse Perl-compatible regexp for patterns with --match. Requires\n+\tlibpcre to be compiled in.\n \n --always::\n \tShow uniquely abbreviated commit object as fallback.\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex 8a25abe..d9ab5bd 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -10,6 +10,10 @@\n #include \"hashmap.h\"\n #include \"argv-array.h\"\n \n+#ifdef USE_LIBPCRE\n+#include \n+#endif\n+\n #define SEEN\t\t(1u << 0)\n #define MAX_TAGS\t(FLAG_BITS - 1)\n \n@@ -19,6 +23,11 @@ static const char * const describe_usage[] = {\n \tNULL\n };\n \n+enum match_type {\n+\tMATCH_GLOB = 0,\n+\tMATCH_PCRE\n+};\n+\n static int debug;\t/* Display lots of verbose info */\n static int all;\t/* Any valid ref can be used */\n static int tags;\t/* Allow lightweight tags */\n@@ -31,6 +40,12 @@ static int have_util;\n static const char *pattern;\n static int always;\n static const char *dirty;\n+static enum match_type pattern_type_arg = MATCH_GLOB;\n+\n+#ifdef USE_LIBPCRE\n+static pcre *pcre_regex = NULL;\n+static pcre_extra *extra = NULL;\n+#endif\n \n /* diff-index command arguments to check if working tree is dirty. */\n static const char *diff_index_args[] = {\n@@ -119,6 +134,61 @@ static void add_to_known_names(const char *path,\n \t}\n }\n \n+#ifdef USE_LIBPCRE\n+static void pcre_init()\n+{\n+\tconst char *error = NULL;\n+\tint erroffset = -1;\n+\tint opts = PCRE_MULTILINE;\n+\n+\tpcre_regex = pcre_compile(pattern, opts, &error, &erroffset, NULL);\n+\tif (!pcre_regex)\n+\t\tdie(\"invalid PCRE at position %d of \\'%s\\': %s\",\n+\t\t\terroffset, pattern, error);\n+\n+\textra = pcre_study(pcre_regex, 0, &error);\n+\tif (!extra && error)\n+\t\tdie(\"%s\", error);\n+}\n+\n+static void pcre_cleanup()\n+{\n+\tpcre_free(pcre_regex);\n+\tpcre_regex = NULL;\n+\tpcre_free(extra);\n+\textra = NULL;\n+}\n+\n+/* return 1 on match, 0 on no match. */\n+static int pcre_match(const char *text)\n+{\n+\tint ovector[3], flags = 0;\n+\tint ret = pcre_exec(pcre_regex, extra,\n+\t text, strlen(text), 0,\n+\t flags, ovector, ARRAY_SIZE(ovector));\n+\tif (ret < 0 && ret != PCRE_ERROR_NOMATCH)\n+\t\tdie(\"pcre_exec failed with error code %d\", ret);\n+\telse if (ret > 0)\n+\t\treturn 0; /* no match */\n+\telse\n+\t\treturn 1; /* match */\n+}\n+#endif\n+\n+/* Return 1 on match, 0 on no match. */\n+static int match(const char *pattern, const char *text, enum match_type t)\n+{\n+\tif (t == MATCH_GLOB) {\n+\t\treturn wildmatch(pattern, text, 0, NULL);\n+#ifdef USE_LIBPCRE\n+\t} else if (t == MATCH_PCRE) {\n+\t\treturn pcre_match(text);\n+#endif\n+\t}\n+\n+\tassert(0); /* None of the alternatives above were used. */\n+}\n+\n static int get_name(const char *path, const struct object_id *oid, int flag, void *cb_data)\n {\n \tint is_tag = starts_with(path, \"refs/tags/\");\n@@ -130,7 +200,7 @@ static int get_name(const char *path, const struct object_id *oid, int flag, voi\n \t\treturn 0;\n \n \t/* Accept only tags that match the pattern, if given */\n-\tif (pattern && (!is_tag || wildmatch(pattern, path + 10, 0, NULL)))\n+\tif (pattern && (!is_tag || match(pattern, path + 10, pattern_type_arg)))\n \t\treturn 0;\n \n \t/* Is it annotated? */\n@@ -406,6 +476,14 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \t\t\t N_(\"consider most recent tags (default: 10)\")),\n \t\tOPT_STRING(0, \"match\", &pattern, N_(\"pattern\"),\n \t\t\t N_(\"only consider tags matching \")),\n+\t\tOPT_SET_INT(0, \"glob\", &pattern_type_arg,\n+\t\t\t N_(\"use glob patterns with --match (default)\"),\n+\t\t\t MATCH_GLOB),\n+#ifdef USE_LIBPCRE\n+\t\tOPT_SET_INT('P', \"perl-regexp\", &pattern_type_arg,\n+\t\t\t N_(\"use Perl-compatible regular expressions with --match\"),\n+\t\t\t MATCH_PCRE),\n+#endif\n \t\tOPT_BOOL(0, \"always\", &always,\n \t\t\tN_(\"show abbreviated commit object as fallback\")),\n \t\t{OPTION_STRING, 0, \"dirty\", &dirty, N_(\"mark\"),\n@@ -429,6 +507,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \tif (longformat && abbrev == 0)\n \t\tdie(_(\"--long is incompatible with --abbrev=0\"));\n \n+#ifdef USE_LIBPCRE\n+\tif (pattern && pattern_type_arg == MATCH_PCRE)\n+\t\tpcre_init();\n+#endif\n+\n \tif (contains) {\n \t\tstruct argv_array args;\n \n@@ -455,6 +538,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \tif (!names.size && !always)\n \t\tdie(_(\"No names found, cannot describe anything.\"));\n \n+#ifdef USE_LIBPCRE\n+\tif (pattern && pattern_type_arg == MATCH_PCRE)\n+\t\tpcre_cleanup();\n+#endif\n+\n \tif (argc == 0) {\n \t\tif (dirty) {\n \t\t\tstatic struct lock_file index_lock;\ndiff --git a/t/README b/t/README\nindex 1dc908e..207257e 100644\n--- a/t/README\n+++ b/t/README\n@@ -798,7 +798,8 @@ use these, and \"test_set_prereq\" for how to define your own.\n - LIBPCRE\n \n Git was compiled with USE_LIBPCRE=YesPlease. Wrap any tests\n- that use git-grep --perl-regexp or git-grep -P in these.\n+ that use the --perl-regexp or -P flags to git-grep or\n+ git-describe in these.\n \n - CASE_INSENSITIVE_FS\n \ndiff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\nindex 85f2694..47427c4 100755\n--- a/t/t6120-describe.sh\n+++ b/t/t6120-describe.sh\n@@ -12,13 +12,14 @@ test_description='test describe\n '\n . ./test-lib.sh\n \n-check_describe () {\n-\texpect=\"$1\"\n-\tshift\n+_check_describe () {\n+\tpcre=\"$1\"\n+\texpect=\"$2\"\n+\tshift 2\n \tR=$(git describe \"$@\" 2>err.actual)\n \tS=$?\n \tcat err.actual >&3\n-\ttest_expect_success \"describe $*\" '\n+\ttest_expect_success $pcre \"describe $*\" '\n \ttest $S = 0 &&\n \tcase \"$R\" in\n \t$expect)\techo happy ;;\n@@ -28,6 +29,14 @@ check_describe () {\n \t'\n }\n \n+check_describe() {\n+\t_check_describe \"\" $*\n+}\n+\n+check_describe_pcre() {\n+\t_check_describe LIBPCRE $*\n+}\n+\n test_expect_success setup '\n \n \ttest_tick &&\n@@ -175,12 +184,19 @@ test_expect_success 'set-up matching pattern tests' '\n '\n \n check_describe \"test-annotated-*\" --match=\"test-*\"\n+check_describe_pcre \"test-annotated-*\" --match=\"^test-\" --perl-regexp\n \n check_describe \"test1-lightweight-*\" --tags --match=\"test1-*\"\n+check_describe_pcre \"test1-lightweight-*\" --tags --match=\"^test1-\" \\\n+\t--perl-regexp\n \n check_describe \"test2-lightweight-*\" --tags --match=\"test2-*\"\n+check_describe_pcre \"test2-lightweight-*\" --tags --match=\"^test2-\" \\\n+\t--perl-regexp\n \n check_describe \"test2-lightweight-*\" --long --tags --match=\"test2-*\" HEAD^\n+check_describe_pcre \"test2-lightweight-*\" --long --tags --match=\"^test2-\" \\\n+\t--perl-regexp HEAD^\n \n test_expect_success 'name-rev with exact tags' '\n \techo A >expect &&\n-- \n2.5.0\n"},{"id":"275042","messageId":"f471c683ff54405dc87941b0f157d19a9ba683ed.1451298323.git.mostynb@opera.com","threadId":"41083","inReplyTo":"cover.1451298323.git.mostynb@opera.com","subject":"[PATCH/RFC v2 2/2] describe: add basic and extended posix regex matching for completeness","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-28T10:30:24Z","receivedAt":"2015-12-28T10:30:24Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"Signed-off-by: Mostyn Bramley-Moore \n---\n Documentation/git-describe.txt | 6 ++++++\n builtin/describe.c | 41 +++++++++++++++++++++++++++++++++++++++++\n t/t6120-describe.sh | 14 ++++++++++++++\n 3 files changed, 61 insertions(+)\n\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex b8279ec..0c237c3 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -89,6 +89,12 @@ OPTIONS\n --glob::\n \tUse `glob(7)` patterns with --match, this is the default.\n \n+-E::\n+--extended-regexp::\n+-G::\n+--basic-regexp::\n+\tUse POSIX extended/basic regexp for patterns with --match.\n+\n -P::\n --perl-regexp::\n \tUse Perl-compatible regexp for patterns with --match. Requires\ndiff --git a/builtin/describe.c b/builtin/describe.c\nindex d9ab5bd..3bff610 100644\n--- a/builtin/describe.c\n+++ b/builtin/describe.c\n@@ -9,6 +9,7 @@\n #include \"diff.h\"\n #include \"hashmap.h\"\n #include \"argv-array.h\"\n+#include \n \n #ifdef USE_LIBPCRE\n #include \n@@ -25,6 +26,8 @@ static const char * const describe_usage[] = {\n \n enum match_type {\n \tMATCH_GLOB = 0,\n+\tMATCH_BRE,\n+\tMATCH_ERE,\n \tMATCH_PCRE\n };\n \n@@ -41,6 +44,7 @@ static const char *pattern;\n static int always;\n static const char *dirty;\n static enum match_type pattern_type_arg = MATCH_GLOB;\n+static regex_t posix_regex;\n \n #ifdef USE_LIBPCRE\n static pcre *pcre_regex = NULL;\n@@ -134,6 +138,27 @@ static void add_to_known_names(const char *path,\n \t}\n }\n \n+static void re_init(enum match_type type)\n+{\n+\tint cflags = REG_NOSUB;\n+\tif (type == MATCH_ERE)\n+\t\tcflags |= REG_EXTENDED;\n+\n+\tif (regcomp(&posix_regex, pattern, cflags))\n+\t\tdie(\"Invalid regular expression: %s\", pattern);\n+}\n+\n+static void re_cleanup()\n+{\n+\tregfree(&posix_regex);\n+}\n+\n+/* return 1 on match, 0 on no match. */\n+static int posix_re_match(const char *text)\n+{\n+\treturn regexec(&posix_regex, text, 0, NULL, 0) != 0;\n+}\n+\n #ifdef USE_LIBPCRE\n static void pcre_init()\n {\n@@ -180,6 +205,8 @@ static int match(const char *pattern, const char *text, enum match_type t)\n {\n \tif (t == MATCH_GLOB) {\n \t\treturn wildmatch(pattern, text, 0, NULL);\n+\t} else if (t == MATCH_ERE || t == MATCH_BRE) {\n+\t\treturn posix_re_match(text);\n #ifdef USE_LIBPCRE\n \t} else if (t == MATCH_PCRE) {\n \t\treturn pcre_match(text);\n@@ -479,6 +506,12 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \t\tOPT_SET_INT(0, \"glob\", &pattern_type_arg,\n \t\t\t N_(\"use glob patterns with --match (default)\"),\n \t\t\t MATCH_GLOB),\n+\t\tOPT_SET_INT('E', \"extended-regexp\", &pattern_type_arg,\n+\t\t\t N_(\"use extended POSIX regular expressions with --match\"),\n+\t\t\t MATCH_ERE),\n+\t\tOPT_SET_INT('G', \"basic-regexp\", &pattern_type_arg,\n+\t\t\t N_(\"use basic POSIX regular expressions with --match\"),\n+\t\t\t MATCH_BRE),\n #ifdef USE_LIBPCRE\n \t\tOPT_SET_INT('P', \"perl-regexp\", &pattern_type_arg,\n \t\t\t N_(\"use Perl-compatible regular expressions with --match\"),\n@@ -507,6 +540,10 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \tif (longformat && abbrev == 0)\n \t\tdie(_(\"--long is incompatible with --abbrev=0\"));\n \n+\tif (pattern && (pattern_type_arg == MATCH_ERE ||\n+\t\t\tpattern_type_arg == MATCH_BRE))\n+\t\tre_init(pattern_type_arg);\n+\n #ifdef USE_LIBPCRE\n \tif (pattern && pattern_type_arg == MATCH_PCRE)\n \t\tpcre_init();\n@@ -538,6 +575,10 @@ int cmd_describe(int argc, const char **argv, const char *prefix)\n \tif (!names.size && !always)\n \t\tdie(_(\"No names found, cannot describe anything.\"));\n \n+\tif (pattern && (pattern_type_arg == MATCH_ERE ||\n+\t\t\tpattern_type_arg == MATCH_BRE))\n+\t\tre_cleanup();\n+\n #ifdef USE_LIBPCRE\n \tif (pattern && pattern_type_arg == MATCH_PCRE)\n \t\tpcre_cleanup();\ndiff --git a/t/t6120-describe.sh b/t/t6120-describe.sh\nindex 47427c4..e3d8663 100755\n--- a/t/t6120-describe.sh\n+++ b/t/t6120-describe.sh\n@@ -184,17 +184,31 @@ test_expect_success 'set-up matching pattern tests' '\n '\n \n check_describe \"test-annotated-*\" --match=\"test-*\"\n+check_describe \"test-annotated-*\" --match=\"^test-\" --basic-regexp\n+check_describe \"test-annotated-*\" --match=\"^test-\" --extended-regexp\n check_describe_pcre \"test-annotated-*\" --match=\"^test-\" --perl-regexp\n \n check_describe \"test1-lightweight-*\" --tags --match=\"test1-*\"\n+check_describe \"test1-lightweight-*\" --tags --match=\"^test1-\" \\\n+\t--extended-regexp\n+check_describe \"test1-lightweight-*\" --tags --match=\"^test1-\" \\\n+\t--basic-regexp\n check_describe_pcre \"test1-lightweight-*\" --tags --match=\"^test1-\" \\\n \t--perl-regexp\n \n check_describe \"test2-lightweight-*\" --tags --match=\"test2-*\"\n+check_describe \"test2-lightweight-*\" --tags --match=\"^test2-\" \\\n+\t--extended-regexp\n+check_describe \"test2-lightweight-*\" --tags --match=\"^test2-\" \\\n+\t--basic-regexp\n check_describe_pcre \"test2-lightweight-*\" --tags --match=\"^test2-\" \\\n \t--perl-regexp\n \n check_describe \"test2-lightweight-*\" --long --tags --match=\"test2-*\" HEAD^\n+check_describe \"test2-lightweight-*\" --long --tags --match=\"test2-*\" \\\n+\t--extended-regexp HEAD^\n+check_describe \"test2-lightweight-*\" --long --tags --match=\"test2-*\" \\\n+\t--basic-regexp HEAD^\n check_describe_pcre \"test2-lightweight-*\" --long --tags --match=\"^test2-\" \\\n \t--perl-regexp HEAD^\n \n-- \n2.5.0\n"},{"id":"275055","messageId":"xmqqy4cejoz4.fsf@gitster.mtv.corp.google.com","threadId":"41083","inReplyTo":"cover.1451298323.git.mostynb@opera.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-28T20:30:07Z","receivedAt":"2015-12-28T20:30:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mostyn Bramley-Moore writes:\n\n> git describe currently only supports glob matching with the --matches flag.\n> It would be useful to support regular expressions.\n>\n> For consistency, this uses the same regex flags as those used by git-grep.\n>\n> Some old discussion of this as a candidate feature is here, though nobody put\n> together a patch as far as I can see:\n> http://comments.gmane.org/gmane.comp.version-control.git/173873\n\nThanks.\n\nI do not think it is wrong per-se to add an option to use regular\nexpressions instead of globs, but if we are to do so, the endgame we\naim for MUST be that we do so consistently to all the other commands\nthat iterate over refs and limit their output to the ones that match\ngiven pattern (or a set of patterns), not just 'describe'.\n\nEven if we are not adding such an option to these other commands\nright now (yet), we at least need to know what these commands are\n(e.g. \"git tag -l\" and \"git for-each-ref\" immediately come to mind,\nbut there may be others), and make sure that the option names you\nchoose here can be used sensibly in their context. I think \"tag\"\nand \"for-each-ref\" do no pattern matching against anything other\nthan the refnames, so it would be clear what a new --perl-regexp\noption does in their contexts.\n\nUnlike \"grep\" whose sole point is to perform pattern matching, the\nfiltering of refs these commands do is merely a very small tweak in\nthe overall picture (e.g. \"git tag --contains $commit -l $pattern\"\ndoes filter by matching $pattern against the refname, but that is a\nsmall detail compared to the filtering done by the reachability with\nthe $commit), so I am not sure if short -E/-G/-F/-P should be given\nto these commands like \"grep\" does, though. These commands may have\nbetter uses for these shorter option names.\n"},{"id":"275064","messageId":"5681D02C.1040609@opera.com","threadId":"41083","inReplyTo":"xmqqy4cejoz4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-29T00:13:32Z","receivedAt":"2015-12-29T00:13:32Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"On 12/28/2015 09:30 PM, Junio C Hamano wrote:\n> Mostyn Bramley-Moore writes:\n>\n>> git describe currently only supports glob matching with the --matches flag.\n>> It would be useful to support regular expressions.\n>>\n>> For consistency, this uses the same regex flags as those used by git-grep.\n>>\n>> Some old discussion of this as a candidate feature is here, though nobody put\n>> together a patch as far as I can see:\n>> http://comments.gmane.org/gmane.comp.version-control.git/173873\n>\n> Thanks.\n>\n> I do not think it is wrong per-se to add an option to use regular\n> expressions instead of globs, but if we are to do so, the endgame we\n> aim for MUST be that we do so consistently to all the other commands\n> that iterate over refs and limit their output to the ones that match\n> given pattern (or a set of patterns), not just 'describe'.\n\nThere is one important distinction between 'git describe' and the other \ncommands that iterate through refs- it applies an internal search \nstrategy and outputs at most one match. This makes it difficult to \nsearch for the closest matching tag that matches any item in a set of \npatterns without some messy scripting (ie run multiple 'git describe' \ncommands, for each pattern, then figure out which result is the one you \nwant).\n\n> Even if we are not adding such an option to these other commands\n> right now (yet), we at least need to know what these commands are\n> (e.g. \"git tag -l\" and \"git for-each-ref\" immediately come to mind,\n> but there may be others), and make sure that the option names you\n> choose here can be used sensibly in their context. I think \"tag\"\n> and \"for-each-ref\" do no pattern matching against anything other\n> than the refnames, so it would be clear what a new --perl-regexp\n> option does in their contexts.\n\nThe commands that you mention produce a list of results, which can \neasily be processed by an external util (eg grep itself), and might not \nneed similar arguments to be added.\n\nAdding regex pattern matching to 'git describe' is just one reasonable \n(IMO) solution, but there are a couple of alternatives that might suffice:\n1) Add an option to print all tags, in a well-defined/useful order. \nThen the results would be easy to process by an external command too.\n2) Add support for multiple patterns, and print the first found item \nthat matches any of them.\n\n> Unlike \"grep\" whose sole point is to perform pattern matching, the\n> filtering of refs these commands do is merely a very small tweak in\n> the overall picture (e.g. \"git tag --contains $commit -l $pattern\"\n> does filter by matching $pattern against the refname, but that is a\n> small detail compared to the filtering done by the reachability with\n> the $commit), so I am not sure if short -E/-G/-F/-P should be given\n> to these commands like \"grep\" does, though. These commands may have\n> better uses for these shorter option names.\n\nBesides 'git grep', the only regex type flag that is given a short \noption seems to be -E for 'git log' and 'git rev-list'. I have no \nobjection to dropping the short options, or leaving only -E.\n\n\n-Mostyn.\n-- \nMostyn Bramley-Moore\nTV and Connected Devices\nOpera Software ASA\nmostynb@opera.com\n"},{"id":"275140","messageId":"xmqqk2nxi002.fsf@gitster.mtv.corp.google.com","threadId":"41083","inReplyTo":"5681D02C.1040609@opera.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-29T18:27:09Z","receivedAt":"2015-12-29T18:27:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mostyn Bramley-Moore writes:\n\n>> I do not think it is wrong per-se to add an option to use regular\n>> expressions instead of globs, but if we are to do so, the endgame we\n>> aim for MUST be that we do so consistently to all the other commands\n>> that iterate over refs and limit their output to the ones that match\n>> given pattern (or a set of patterns), not just 'describe'.\n>\n> There is one important distinction between 'git describe' and the\n> other commands that iterate through refs- it applies an internal\n> search strategy and outputs at most one match. This makes it\n> difficult to search for the closest matching tag...\n\nIf that was what you were trying to solve, then it sounds like a\ntypical XY problem. You do not need custom matching flags; you need\na \"give me N (or all) names based on possible tags\" option.\n\nAnd I do not think it is a bad thing to add. I already\nsaid that an option to match with a regular expression is not a bad\nthing to add, either ;-)\n\n> Besides 'git grep', the only regex type flag that is given a short\n> option seems to be -E for 'git log' and 'git rev-list'. I have no\n> objection to dropping the short options, or leaving only -E.\n\nThey also take -F, but \"log\" and friends do not pattern match the\nrefnames, so I do not think you have to worry about them at the\nmoment.\n\nIt is more important to envision what we would do in the future when\na command that takes a pattern (or a set of patterns) to match the\nrefnames with _and_ another pattern (or a set of patterns) to match\nsomething else, and take that into account when designing this\n\"allowing matching logic for refnames to be customized from glob to\nsomething else\" feature, so that we do not paint outselves into a\ncorner we cannot later get out of. Imagine a hypothetical command\n'git mgrep' that can look for a pattern in tips of multiple branches\nthat can be used this way:\n\n $ git mgrep -e 'froo*tz' --refs 'refs/heads/release/*'\n\nwhich may look for strings that match \"froo*tz\" in the trees of\nall branches whose name match the pattern 'release/*'. In this\nexample, the pattern to match strings is a BRE (same default as \n\"git grep\"), and the pattern to match refnames is a glob.\n\nConsistency & similarity with \"git grep\" would most likely lead us\nto add -E/-F/-G/-P options to this command and to make it affect how\nthe pattern to match strings works. For example:\n\n $ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/*'\n\nmay look for the same strings that would match the first example,\nbut the pattern is expressed in ERE. \"-P\", \"-G\", and \"-F\" options\nwould also work the same way.\n\nNow, the question is what this \"-E\" (or -P/-G/-F) should do with the\nmatching the command does with the refnames. The easiest (and\nlaziest) way out from the implementors' point of view might be to\ndeclare that they affect both at the same time. But is that useful\nin practice? It probably isn't, as it forces the users to write\n\n $ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/.*'\n\nbecause the ref matching suddenly starts to use ERE (not glob),\nwhich most likely is not something users would expect. So we may\nneed a separate set of options to affect the way how refs are\nmatched.\n\nWe cannot just say \"but we do not have that 'mgrep' command yet, so\nwe can do whatever we want to do with 'describe' today\". When the\nneed eventually arises that requires us to be able to specify how\nstrings are matched and how refnames are matched independently, we\nwould end up with an inconsistent UI where 'describe' takes '-P' (or\n'--perl-regexp') to affect the way how refnames are matched, while\ncommands like 'mgrep' would need to use '--refmatch-perl-regexp' (or\nany other name that can be distinguished from '--perl-regexp') to do\nthe same thing because they do not want '--perl-regexp' to affect\nthe matching of refnames.\n\nAnd at that point in the future, it is too late to fix 'describe',\nas people are so used to use '--perl-regexp' to match with refs. We\nwill forever regret that we did not give the option a name that can\nbe used independently from the existing '--perl-regexp' that is\nabout matching for strings, not refnames.\n\nThat is exactly the kind of thing that would paint us in a corner\nthat we cannot get out of, which we need to avoid, hence we need to\nthink ahead now.\n \n"},{"id":"275172","messageId":"CACsJy8ADrHW=Tr2Tx04NoAKP3MfP__Ndjut_G_7HitLPHKn46w@mail.gmail.com","threadId":"41083","inReplyTo":"xmqqk2nxi002.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2015-12-30T09:52:15Z","receivedAt":"2015-12-30T09:52:15Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Dec 30, 2015 at 1:27 AM, Junio C Hamano wrote:\n> It is more important to envision what we would do in the future when\n> a command that takes a pattern (or a set of patterns) to match the\n> refnames with _and_ another pattern (or a set of patterns) to match\n> something else, and take that into account when designing this\n> \"allowing matching logic for refnames to be customized from glob to\n> something else\" feature, so that we do not paint outselves into a\n> corner we cannot later get out of. Imagine a hypothetical command\n> 'git mgrep' that can look for a pattern in tips of multiple branches\n> that can be used this way:\n>\n> $ git mgrep -e 'froo*tz' --refs 'refs/heads/release/*'\n>\n> which may look for strings that match \"froo*tz\" in the trees of\n> all branches whose name match the pattern 'release/*'. In this\n> example, the pattern to match strings is a BRE (same default as\n> \"git grep\"), and the pattern to match refnames is a glob.\n>\n> Consistency & similarity with \"git grep\" would most likely lead us\n> to add -E/-F/-G/-P options to this command and to make it affect how\n> the pattern to match strings works. For example:\n>\n> $ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/*'\n>\n> may look for the same strings that would match the first example,\n> but the pattern is expressed in ERE. \"-P\", \"-G\", and \"-F\" options\n> would also work the same way.\n>\n> Now, the question is what this \"-E\" (or -P/-G/-F) should do with the\n> matching the command does with the refnames. The easiest (and\n> laziest) way out from the implementors' point of view might be to\n> declare that they affect both at the same time.\n> ...\n\nWhat about not using command line options? We could go with something\nlike pathspec magic. I think as long as we provide three options:\nliteral, some pattern matching and backquote, then the user has enough\nflexibility to specify any set of refs. For pattern matching I'd\nprefer wildmatch. regex can be used via backquote, e.g. `for-each-ref\n| grep ...` (or teach for-each-ref about regex to avoid grep).\n-- \nDuy\n"},{"id":"275219","messageId":"5684702C.3040802@opera.com","threadId":"41083","inReplyTo":"xmqqk2nxi002.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-31T00:00:44Z","receivedAt":"2015-12-31T00:00:44Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"On 12/29/2015 07:27 PM, Junio C Hamano wrote:\n> Mostyn Bramley-Moore writes:\n>\n>>> I do not think it is wrong per-se to add an option to use regular\n>>> expressions instead of globs, but if we are to do so, the endgame we\n>>> aim for MUST be that we do so consistently to all the other commands\n>>> that iterate over refs and limit their output to the ones that match\n>>> given pattern (or a set of patterns), not just 'describe'.\n>>\n>> There is one important distinction between 'git describe' and the\n>> other commands that iterate through refs- it applies an internal\n>> search strategy and outputs at most one match. This makes it\n>> difficult to search for the closest matching tag...\n>\n> If that was what you were trying to solve, then it sounds like a\n> typical XY problem. You do not need custom matching flags; you need\n> a \"give me N (or all) names based on possible tags\" option.\n\nI can submit a separate patch for this, if you think it makes sense. \nSome possibilities that spring to mind:\n* --results=\n* --num-results=\n* --show-matches=\n* --multiple-results[=]\n* --all-matches\n* -\n\n> And I do not think it is a bad thing to add. I already\n> said that an option to match with a regular expression is not a bad\n> thing to add, either ;-)\n>\n>> Besides 'git grep', the only regex type flag that is given a short\n>> option seems to be -E for 'git log' and 'git rev-list'. I have no\n>> objection to dropping the short options, or leaving only -E.\n>\n> They also take -F, but \"log\" and friends do not pattern match the\n> refnames, so I do not think you have to worry about them at the\n> moment.\n>\n> It is more important to envision what we would do in the future when\n> a command that takes a pattern (or a set of patterns) to match the\n> refnames with _and_ another pattern (or a set of patterns) to match\n> something else, and take that into account when designing this\n> \"allowing matching logic for refnames to be customized from glob to\n> something else\" feature, so that we do not paint outselves into a\n> corner we cannot later get out of. Imagine a hypothetical command\n> 'git mgrep' that can look for a pattern in tips of multiple branches\n> that can be used this way:\n>\n> $ git mgrep -e 'froo*tz' --refs 'refs/heads/release/*'\n>\n> which may look for strings that match \"froo*tz\" in the trees of\n> all branches whose name match the pattern 'release/*'. In this\n> example, the pattern to match strings is a BRE (same default as\n> \"git grep\"), and the pattern to match refnames is a glob.\n>\n> Consistency & similarity with \"git grep\" would most likely lead us\n> to add -E/-F/-G/-P options to this command and to make it affect how\n> the pattern to match strings works. For example:\n>\n> $ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/*'\n>\n> may look for the same strings that would match the first example,\n> but the pattern is expressed in ERE. \"-P\", \"-G\", and \"-F\" options\n> would also work the same way.\n>\n> Now, the question is what this \"-E\" (or -P/-G/-F) should do with the\n> matching the command does with the refnames. The easiest (and\n> laziest) way out from the implementors' point of view might be to\n> declare that they affect both at the same time. But is that useful\n> in practice? It probably isn't, as it forces the users to write\n>\n> $ git mgrep -E -e 'fro+tz' --match-refs 'refs/heads/release/.*'\n>\n> because the ref matching suddenly starts to use ERE (not glob),\n> which most likely is not something users would expect. So we may\n> need a separate set of options to affect the way how refs are\n> matched.\n>\n> We cannot just say \"but we do not have that 'mgrep' command yet, so\n> we can do whatever we want to do with 'describe' today\". When the\n> need eventually arises that requires us to be able to specify how\n> strings are matched and how refnames are matched independently, we\n> would end up with an inconsistent UI where 'describe' takes '-P' (or\n> '--perl-regexp') to affect the way how refnames are matched, while\n> commands like 'mgrep' would need to use '--refmatch-perl-regexp' (or\n> any other name that can be distinguished from '--perl-regexp') to do\n> the same thing because they do not want '--perl-regexp' to affect\n> the matching of refnames.\n>\n> And at that point in the future, it is too late to fix 'describe',\n> as people are so used to use '--perl-regexp' to match with refs. We\n> will forever regret that we did not give the option a name that can\n> be used independently from the existing '--perl-regexp' that is\n> about matching for strings, not refnames.\n>\n> That is exactly the kind of thing that would paint us in a corner\n> that we cannot get out of, which we need to avoid, hence we need to\n> think ahead now.\n\nOK, brainstorming a bit, how about either of these:\n\n1) \n--match-pattern-type=\n\nIt's a bit lengthy (maybe --match-type would be sufficient), but I like \nthat the value names are shared with git grep etc option names. And it \nseems future-proof- if we ever need to support different pattern types \nfor other arguments, a --foo-pattern-type flag could be added and make \nobvious sense.\n\n2) Interpret --match patterns that start and end with / as regular \nexpressions, and just pick one regex type to support. I would suggest \nextended posix regex (since it's supported in all builds unlike PCRE). \nDownsides: some people might assume this is PCRE, also if we ever wanted \nto support other regex types we would need to add another option like \n(1), which would then make this feature redundant.\n\nI prefer (1).\n\n\n-Mostyn.\n-- \nMostyn Bramley-Moore\nTV and Connected Devices\nOpera Software ASA\nmostynb@opera.com\n"},{"id":"275221","messageId":"5684720B.40208@opera.com","threadId":"41083","inReplyTo":"CACsJy8ADrHW=Tr2Tx04NoAKP3MfP__Ndjut_G_7HitLPHKn46w@mail.gmail.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-31T00:08:43Z","receivedAt":"2015-12-31T00:08:43Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"On 12/30/2015 10:52 AM, Duy Nguyen wrote:\n> What about not using command line options? We could go with something\n> like pathspec magic. I think as long as we provide three options:\n> literal, some pattern matching and backquote, then the user has enough\n> flexibility to specify any set of refs. For pattern matching I'd\n> prefer wildmatch. regex can be used via backquote, e.g. `for-each-ref\n> | grep ...` (or teach for-each-ref about regex to avoid grep).\n\nI don't think that would solve my immediate problem, unless git \nfor-each-ref knew how to produce output in the same order that git \ndescribe searches. But perhaps I misunderstand what you're suggesting \nwith the backquote/subshell.\n\n\n-Mostyn.\n-- \nMostyn Bramley-Moore\nTV and Connected Devices\nOpera Software ASA\nmostynb@opera.com\n"},{"id":"275223","messageId":"xmqqy4cbbh5e.fsf@gitster.mtv.corp.google.com","threadId":"41083","inReplyTo":"5684702C.3040802@opera.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-31T00:23:09Z","receivedAt":"2015-12-31T00:23:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mostyn Bramley-Moore writes:\n\n> OK, brainstorming a bit, how about either of these:\n>\n> 1)\n> --match-pattern-type=\n>\n> It's a bit lengthy (maybe --match-type would be sufficient), but I\n> like that the value names are shared with git grep etc option names.\n> And it seems future-proof- if we ever need to support different\n> pattern types for other arguments, a --foo-pattern-type flag could be\n> added and make obvious sense.\n\nSwapping the option key and value may not be a bad idea, but one\nproblem that the above does not solve, which I outlined in the\nmessage you are responding to, is that \"match-pattern-type\" does not\ngive any hint that this is about affecting the match that is done to\n\"refs\", e.g. you cannot tell in\n\n $ git mgrep --match-pattern-type=perl-regexp -e foo --refs 'release_*'\n\nif the perl-regexp is to be used for matching branch names or for\nmatching the strings the command looks for in the trees of the\nmatching branches.\n\nMagic pattern annotation like we do for pathspecs Duy raised may not\nbe a bad idea, either, and would probably be easier to teach people.\nJust like in Perl \"(?i)$any_pattern\" is a way to introduce the case\ninsensitive match with $any_pattern, we may be able to pick an\nextensible magic syntax and decorate the pattern you would specify\nfor matching refnames to tell Git what kind of pattern it is, e.g.\n\n $ git mgrep -P -e foo --refs '/?glob/release_*'\n\nI am not suggesting that we must use /?/ prefix\nas the \"extensible magic syntax\" here--I am just illustrating what\nI mean by \"extensible magic syntax\".\n"},{"id":"275234","messageId":"5684FE61.4010701@opera.com","threadId":"41083","inReplyTo":"xmqqy4cbbh5e.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2015-12-31T10:07:29Z","receivedAt":"2015-12-31T10:07:29Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"On 12/31/2015 01:23 AM, Junio C Hamano wrote:\n> Mostyn Bramley-Moore writes:\n>\n>> OK, brainstorming a bit, how about either of these:\n>>\n>> 1)\n>> --match-pattern-type=\n>>\n>> It's a bit lengthy (maybe --match-type would be sufficient), but I\n>> like that the value names are shared with git grep etc option names.\n>> And it seems future-proof- if we ever need to support different\n>> pattern types for other arguments, a --foo-pattern-type flag could be\n>> added and make obvious sense.\n>\n> Swapping the option key and value may not be a bad idea, but one\n> problem that the above does not solve, which I outlined in the\n> message you are responding to, is that \"match-pattern-type\" does not\n> give any hint that this is about affecting the match that is done to\n> \"refs\", e.g. you cannot tell in\n>\n> $ git mgrep --match-pattern-type=perl-regexp -e foo --refs 'release_*'\n>\n> if the perl-regexp is to be used for matching branch names or for\n> matching the strings the command looks for in the trees of the\n> matching branches.\n\nThere is a hint: --foo-pattern-type applies only to --foo.\n\nIn your mgrep example --match-pattern-type would apply to --match \npatterns only, and if we choose to implement it then --refs-pattern-type \nwould apply to --refs patterns only.\n\neg:\n$ git mgrep --match '^foo' --match-pattern-type=perl-regexp --refs \n'release_*' --refs-pattern-type=glob\n\n> Magic pattern annotation like we do for pathspecs Duy raised may not\n> be a bad idea, either, and would probably be easier to teach people.\n> Just like in Perl \"(?i)$any_pattern\" is a way to introduce the case\n> insensitive match with $any_pattern, we may be able to pick an\n> extensible magic syntax and decorate the pattern you would specify\n> for matching refnames to tell Git what kind of pattern it is, e.g.\n>\n> $ git mgrep -P -e foo --refs '/?glob/release_*'\n>\n> I am not suggesting that we must use /?/ prefix\n> as the \"extensible magic syntax\" here--I am just illustrating what\n> I mean by \"extensible magic syntax\".\n\nI hadn't seen the pathspec magic patterns before- interesting. We could \npossibly share syntax with pathspecs, ie\n:(?pattern-options...)pattern\n\nWould this be confusing for commands that already have --perl-regexp \netc? What should happen if you specify both --perl-regexp and and a \ndifferent type of pattern like :(glob)foo (error out, I suppose)?\n\n\n-Mostyn.\n-- \nMostyn Bramley-Moore\nTV and Connected Devices\nOpera Software ASA\nmostynb@opera.com\n"},{"id":"275309","messageId":"xmqqmvslp799.fsf@gitster.mtv.corp.google.com","threadId":"41083","inReplyTo":"5684FE61.4010701@opera.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-04T17:46:42Z","receivedAt":"2016-01-04T17:46:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mostyn Bramley-Moore writes:\n\n> On 12/31/2015 01:23 AM, Junio C Hamano wrote:\n> ...\n>> Swapping the option key and value may not be a bad idea, but one\n>> problem that the above does not solve, which I outlined in the\n>> message you are responding to, is that \"match-pattern-type\" does not\n>> give any hint that this is about affecting the match that is done to\n>> \"refs\", e.g. you cannot tell in\n>>\n>> $ git mgrep --match-pattern-type=perl-regexp -e foo --refs 'release_*'\n>>\n>> if the perl-regexp is to be used for matching branch names or for\n>> matching the strings the command looks for in the trees of the\n>> matching branches.\n>\n> There is a hint: --foo-pattern-type applies only to --foo.\n\nHmph.\n\n> In your mgrep example --match-pattern-type would apply to --match\n> patterns only, and if we choose to implement it then\n> --refs-pattern-type would apply to --refs patterns only.\n> eg:\n> $ git mgrep --match '^foo' --match-pattern-type=perl-regexp --refs\n> release_*' --refs-pattern-type=glob\n\nMost likely the hypothetical \"mgrep\" would not use \"--match\" but use\n\"-e\" to retain similarity to \"grep\", and \"--e-pattern-type\" would be\nconfusing. But I agree that \"--refs-pattern-type\" uniformly used\nwhere we take pattern parameter on the command line to match with\nrefs may make it clear that you are only affecting the matches\nagainst refs.\n\n>> Magic pattern annotation like we do for pathspecs Duy raised may not\n>> be a bad idea, either, and would probably be easier to teach people.\n>> Just like in Perl \"(?i)$any_pattern\" is a way to introduce the case\n>> insensitive match with $any_pattern, we may be able to pick an\n>> extensible magic syntax and decorate the pattern you would specify\n>> for matching refnames to tell Git what kind of pattern it is, e.g.\n>>\n>> $ git mgrep -P -e foo --refs '/?glob/release_*'\n>>\n>> I am not suggesting that we must use /?/ prefix\n>> as the \"extensible magic syntax\" here--I am just illustrating what\n>> I mean by \"extensible magic syntax\".\n>\n> I hadn't seen the pathspec magic patterns before- interesting. We\n> could possibly share syntax with pathspecs, ie\n> :(?pattern-options...)pattern\n\nEven though we have DWIM between revisions and paths on the command\nline when the user omits \"--\" for disambiguation, I do not think we\nlook at the shape of the string to DWIM/decide that it is a pattern,\nso as long as the magic syntax cannot be a valid pattern to match\nagainst refs right now (and your \":(?...)\" qualifies as such, as a\nrefname would not contain a component that begins with a colon), it\nwould be possible to introduce it as the magic syntax for matching\nrefs.\n\nOr did you mean to use this syntax also for patterns that match\nstrings in contents, e.g.\n\n $ git grep -e ':(?perl-regexp)...'\n\nI am not bold enough to say that it would be a good idea, but I\noffhand do not think of a reason why we shouldn't go that route,\neither.\n\n> Would this be confusing for commands that already have --perl-regexp\n> etc? What should happen if you specify both --perl-regexp and and a\n> different type of pattern like :(glob)foo (error out, I suppose)?\n\nIf we were to go that route, ideally, I would say that\n\n $ git grep --perl-regexp -e 'A' -e ':(?basic-regexp)B' -e ':(?fixed-string)C'\n\nshould match with A as pcre, B as BRE and C as a fixed string.\n\nI do not offhand remember if we built the underlying grep machinery\nin such a way that it is easy to extend it to allow such mixture,\nthough.\n"},{"id":"275409","messageId":"568C690C.7050007@opera.com","threadId":"41083","inReplyTo":"xmqqmvslp799.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Mostyn Bramley-Moore","fromEmail":"mostynb@opera.com","sentAt":"2016-01-06T01:08:28Z","receivedAt":"2016-01-06T01:08:28Z","isPatch":true,"sender":{"key":"mostynb@opera.com","avatar":null},"body":"On 01/04/2016 06:46 PM, Junio C Hamano wrote:\n> Mostyn Bramley-Moore writes:\n>\n>> On 12/31/2015 01:23 AM, Junio C Hamano wrote:\n>> ...\n>>> Swapping the option key and value may not be a bad idea, but one\n>>> problem that the above does not solve, which I outlined in the\n>>> message you are responding to, is that \"match-pattern-type\" does not\n>>> give any hint that this is about affecting the match that is done to\n>>> \"refs\", e.g. you cannot tell in\n>>>\n>>> $ git mgrep --match-pattern-type=perl-regexp -e foo --refs 'release_*'\n>>>\n>>> if the perl-regexp is to be used for matching branch names or for\n>>> matching the strings the command looks for in the trees of the\n>>> matching branches.\n>>\n>> There is a hint: --foo-pattern-type applies only to --foo.\n>\n> Hmph.\n>\n>> In your mgrep example --match-pattern-type would apply to --match\n>> patterns only, and if we choose to implement it then\n>> --refs-pattern-type would apply to --refs patterns only.\n>> eg:\n>> $ git mgrep --match '^foo' --match-pattern-type=perl-regexp --refs\n>> release_*' --refs-pattern-type=glob\n>\n> Most likely the hypothetical \"mgrep\" would not use \"--match\" but use\n> \"-e\" to retain similarity to \"grep\", and \"--e-pattern-type\" would be\n> confusing. But I agree that \"--refs-pattern-type\" uniformly used\n> where we take pattern parameter on the command line to match with\n> refs may make it clear that you are only affecting the matches\n> against refs.\n\nI don't think -e foo --e-pattern-type=bar would be confusing.\n\n>>> Magic pattern annotation like we do for pathspecs Duy raised may not\n>>> be a bad idea, either, and would probably be easier to teach people.\n>>> Just like in Perl \"(?i)$any_pattern\" is a way to introduce the case\n>>> insensitive match with $any_pattern, we may be able to pick an\n>>> extensible magic syntax and decorate the pattern you would specify\n>>> for matching refnames to tell Git what kind of pattern it is, e.g.\n>>>\n>>> $ git mgrep -P -e foo --refs '/?glob/release_*'\n>>>\n>>> I am not suggesting that we must use /?/ prefix\n>>> as the \"extensible magic syntax\" here--I am just illustrating what\n>>> I mean by \"extensible magic syntax\".\n>>\n>> I hadn't seen the pathspec magic patterns before- interesting. We\n>> could possibly share syntax with pathspecs, ie\n>> :(?pattern-options...)pattern\n>\n> Even though we have DWIM between revisions and paths on the command\n> line when the user omits \"--\" for disambiguation, I do not think we\n> look at the shape of the string to DWIM/decide that it is a pattern,\n> so as long as the magic syntax cannot be a valid pattern to match\n> against refs right now (and your \":(?...)\" qualifies as such, as a\n> refname would not contain a component that begins with a colon), it\n> would be possible to introduce it as the magic syntax for matching\n> refs.\n>\n> Or did you mean to use this syntax also for patterns that match\n> strings in contents, e.g.\n>\n> $ git grep -e ':(?perl-regexp)...'\n\nI think it would be nice to support this syntax in every command that \ndoes pattern matching.\n\nCorner case: what if we want to search for \":(?perl-regexp)\", eg in \ngit's own source? I suppose this would do:\ngit grep -e \":(?fixed-strings):(?perl-regexp)\"\n\n> I am not bold enough to say that it would be a good idea, but I\n> offhand do not think of a reason why we shouldn't go that route,\n> either.\n>\n>> Would this be confusing for commands that already have --perl-regexp\n>> etc? What should happen if you specify both --perl-regexp and and a\n>> different type of pattern like :(glob)foo (error out, I suppose)?\n>\n> If we were to go that route, ideally, I would say that\n>\n> $ git grep --perl-regexp -e 'A' -e ':(?basic-regexp)B' -e ':(?fixed-string)C'\n>\n> should match with A as pcre, B as BRE and C as a fixed string.\n\nThat makes sense.\n\n> I do not offhand remember if we built the underlying grep machinery\n> in such a way that it is easy to extend it to allow such mixture,\n> though.\n\nI believe this would require some moderate refactoring, but I have only \nlooked briefly so far. If we can settle on a preliminary design \n(--foo-pattern-type vs magic pattern option strings), I can try \nimplementing a proof-of-concept.\n\n\n-Mostyn.\n-- \nMostyn Bramley-Moore\nTV and Connected Devices\nOpera Software ASA\nmostynb@opera.com\n"},{"id":"275431","messageId":"CACsJy8AOxs9EizWabdPdEpx6PkPFmv-ZiAtQbdXWV9zDia13Lw@mail.gmail.com","threadId":"41083","inReplyTo":"568C690C.7050007@opera.com","subject":"Re: [PATCH/RFC v2 0/2] add regex match flags to git describe","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-01-06T12:23:05Z","receivedAt":"2016-01-06T12:23:05Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jan 6, 2016 at 8:08 AM, Mostyn Bramley-Moore wrote:\n> On 01/04/2016 06:46 PM, Junio C Hamano wrote:\n>>>> Magic pattern annotation like we do for pathspecs Duy raised may not\n>>>> be a bad idea, either, and would probably be easier to teach people.\n>>>> Just like in Perl \"(?i)$any_pattern\" is a way to introduce the case\n>>>> insensitive match with $any_pattern, we may be able to pick an\n>>>> extensible magic syntax and decorate the pattern you would specify\n>>>> for matching refnames to tell Git what kind of pattern it is, e.g.\n>>>>\n>>>> $ git mgrep -P -e foo --refs '/?glob/release_*'\n>>>>\n>>>> I am not suggesting that we must use /?/ prefix\n>>>> as the \"extensible magic syntax\" here--I am just illustrating what\n>>>> I mean by \"extensible magic syntax\".\n>>>\n>>>\n>>> I hadn't seen the pathspec magic patterns before- interesting. We\n>>> could possibly share syntax with pathspecs, ie\n>>> :(?pattern-options...)pattern\n>>\n>>\n>> Even though we have DWIM between revisions and paths on the command\n>> line when the user omits \"--\" for disambiguation, I do not think we\n>> look at the shape of the string to DWIM/decide that it is a pattern,\n>> so as long as the magic syntax cannot be a valid pattern to match\n>> against refs right now (and your \":(?...)\" qualifies as such, as a\n>> refname would not contain a component that begins with a colon), it\n>> would be possible to introduce it as the magic syntax for matching\n>> refs.\n>>\n>> Or did you mean to use this syntax also for patterns that match\n>> strings in contents, e.g.\n>>\n>> $ git grep -e ':(?perl-regexp)...'\n>\n>\n> I think it would be nice to support this syntax in every command that does\n> pattern matching.\n>\n> Corner case: what if we want to search for \":(?perl-regexp)\", eg in git's\n> own source? I suppose this would do:\n> git grep -e \":(?fixed-strings):(?perl-regexp)\"\n\nWe can also override it with command line options. If you define\n--perl-regexp as \"if no regex syntax is specified in the pattern, pcre\nis used\", then you can have something like --force-perl-regexp that\nsays \"all patterns are in pcre, there's no magic whatsoever to choose\na different regex syntax\". Though I think --perl-regexp should play\nthe role of --force-perl-regexp so you don't surprise current scripts,\nand have a new option --default-syntax= instead.\n-- \nDuy\n"}]}