{"thread":{"id":"48634","subject":"[PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","startedAt":"2018-06-03T10:16:58Z","lastAt":"2018-06-04T13:33:40Z","messageCount":6,"participants":["Robert P. J. Day","Thomas Gummerer","Philip Oakley","Junio C Hamano"],"isPatch":true,"patchVersion":2,"patchTotal":null},"messages":[{"id":"349132","messageId":"alpine.LFD.2.21.1806030613080.7681@localhost.localdomain","threadId":"48634","inReplyTo":null,"subject":"[PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-06-03T10:14:44Z","receivedAt":"2018-06-03T10:16:58Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\nEven though \"--get-regex\" appears to work with \"git config\", the\nclear standard is to spell out the action in full.\n\nSigned-off-by: Robert P. J. Day \n\n---\n\nthis is the only occurrence i saw of this in the entire code base, so\nit seemed worth tweaking just for consistency.\n\ndiff --git a/t/perf/run b/t/perf/run\nindex 9aaa733c7..fb5753ea2 100755\n--- a/t/perf/run\n+++ b/t/perf/run\n@@ -110,7 +110,7 @@ run_dirs () {\n get_subsections () {\n \tsection=\"$1\"\n \ttest -z \"$GIT_PERF_CONFIG_FILE\" && return\n-\tgit config -f \"$GIT_PERF_CONFIG_FILE\" --name-only --get-regex \"$section\\..*\\.[^.]+\" |\n+\tgit config -f \"$GIT_PERF_CONFIG_FILE\" --name-only --get-regexp \"$section\\..*\\.[^.]+\" |\n \tsed -e \"s/$section\\.\\(.*\\)\\..*/\\1/\" | sort | uniq\n }\n\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca/dokuwiki\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"349141","messageId":"20180603133039.GF26159@hank.intra.tgummerer.com","threadId":"48634","inReplyTo":"alpine.LFD.2.21.1806030613080.7681@localhost.localdomain","subject":"Re: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2018-06-03T13:30:39Z","receivedAt":"2018-06-03T13:30:05Z","isPatch":true,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"> Subject: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not\n\nmicronit: we prefer starting with a lowercase letter after the \"area:\"\nprefix in commit messages. Junio can probably fix that while\nqueuing, so no need to resend.\n\nOn 06/03, Robert P. J. Day wrote:\n> \n> Even though \"--get-regex\" appears to work with \"git config\", the\n> clear standard is to spell out the action in full.\n\n--get-regex works as the parse-option API allows abbreviations of the\nfull option to be specified as long as the abbreviation is\nunambiguos. I don't know if this is documented anywhere other than\n'Documentation/technical/api-parse-options.txt' though.\n\n> Signed-off-by: Robert P. J. Day \n> \n> ---\n\nIt took me a bit to figure out why there is a v2, and what changed\nbetween the versions. This space after the '---' would be a good\nplace to describe that to help reviewers.\n\nFor others that are curious, it seems like the word \"clear\" was added\nin the commit message.\n\nThe change itself looks good to me.\n\n> this is the only occurrence i saw of this in the entire code base, so\n> it seemed worth tweaking just for consistency.\n> \n> diff --git a/t/perf/run b/t/perf/run\n> index 9aaa733c7..fb5753ea2 100755\n> --- a/t/perf/run\n> +++ b/t/perf/run\n> @@ -110,7 +110,7 @@ run_dirs () {\n> get_subsections () {\n> \tsection=\"$1\"\n> \ttest -z \"$GIT_PERF_CONFIG_FILE\" && return\n> -\tgit config -f \"$GIT_PERF_CONFIG_FILE\" --name-only --get-regex \"$section\\..*\\.[^.]+\" |\n> +\tgit config -f \"$GIT_PERF_CONFIG_FILE\" --name-only --get-regexp \"$section\\..*\\.[^.]+\" |\n> \tsed -e \"s/$section\\.\\(.*\\)\\..*/\\1/\" | sort | uniq\n> }\n> \n> \n> -- \n> \n> ========================================================================\n> Robert P. J. Day Ottawa, Ontario, CANADA\n> http://crashcourse.ca/dokuwiki\n> \n> Twitter: http://twitter.com/rpjday\n> LinkedIn: http://ca.linkedin.com/in/rpjday\n> ========================================================================\n"},{"id":"349142","messageId":"alpine.LFD.2.21.1806030935010.21364@localhost.localdomain","threadId":"48634","inReplyTo":"20180603133039.GF26159@hank.intra.tgummerer.com","subject":"Re: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-06-03T13:36:40Z","receivedAt":"2018-06-03T13:38:52Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sun, 3 Jun 2018, Thomas Gummerer wrote:\n\n> > Subject: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not\n>\n> micronit: we prefer starting with a lowercase letter after the \"area:\"\n> prefix in commit messages. Junio can probably fix that while\n> queuing, so no need to resend.\n\n argh, i actually know that, i just screwed up.\n\n> On 06/03, Robert P. J. Day wrote:\n> >\n> > Even though \"--get-regex\" appears to work with \"git config\", the\n> > clear standard is to spell out the action in full.\n>\n> --get-regex works as the parse-option API allows abbreviations of the\n> full option to be specified as long as the abbreviation is\n> unambiguos. I don't know if this is documented anywhere other than\n> 'Documentation/technical/api-parse-options.txt' though.\n>\n> > Signed-off-by: Robert P. J. Day \n> >\n> > ---\n>\n> It took me a bit to figure out why there is a v2, and what changed\n> between the versions. This space after the '---' would be a good\n> place to describe that to help reviewers.\n>\n> For others that are curious, it seems like the word \"clear\" was added\n> in the commit message.\n>\n> The change itself looks good to me.\n\n the actual rationale for v2 was in the subject, i originally put\njust \"get-regex\" rather then \"--get-regex\"; i resubmitted for\nconsistency.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca/dokuwiki\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"349152","messageId":"0AE4648A05C445FBA049864F455B35A7@PhilipOakley","threadId":"48634","inReplyTo":"alpine.LFD.2.21.1806030935010.21364@localhost.localdomain","subject":"Re: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2018-06-03T15:33:40Z","receivedAt":"2018-06-03T15:33:50Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Robert P. J. Day\" \n> On Sun, 3 Jun 2018, Thomas Gummerer wrote:\n>\n>> > Subject: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not\n>>\n>> micronit: we prefer starting with a lowercase letter after the \"area:\"\n>> prefix in commit messages. Junio can probably fix that while\n>> queuing, so no need to resend.\n>\n> argh, i actually know that, i just screwed up.\n>\n>> On 06/03, Robert P. J. Day wrote:\n>> >\n>> > Even though \"--get-regex\" appears to work with \"git config\", the\n>> > clear standard is to spell out the action in full.\n>>\n>> --get-regex works as the parse-option API allows abbreviations of the\n>> full option to be specified as long as the abbreviation is\n>> unambiguos. I don't know if this is documented anywhere other than\n>> 'Documentation/technical/api-parse-options.txt' though.\n\nit's in `git help cli`:\n\nmany commands allow a long option --option to be abbreviated only to their \nunique prefix (e.g. if there is no other option whose name begins with opt, \nyou may be able to spell --opt to invoke the --option flag), but you should \nfully spell them out when writing your scripts;\n\nIt's a worthwile read, even if the man page isn't flagged up that often.\n\n>>\n>> > Signed-off-by: Robert P. J. Day \n>> >\n>> > ---\n>>\n>> It took me a bit to figure out why there is a v2, and what changed\n>> between the versions. This space after the '---' would be a good\n>> place to describe that to help reviewers.\n>>\n>> For others that are curious, it seems like the word \"clear\" was added\n>> in the commit message.\n>>\n>> The change itself looks good to me.\n>\n> the actual rationale for v2 was in the subject, i originally put\n> just \"get-regex\" rather then \"--get-regex\"; i resubmitted for\n> consistency.\n>\n--\nPhilip \n\n"},{"id":"349226","messageId":"alpine.LFD.2.21.1806040659590.11594@localhost.localdomain","threadId":"48634","inReplyTo":"0AE4648A05C445FBA049864F455B35A7@PhilipOakley","subject":"Re: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-06-04T11:03:25Z","receivedAt":"2018-06-04T11:05:42Z","isPatch":true,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Sun, 3 Jun 2018, Philip Oakley wrote:\n\n> From: \"Robert P. J. Day\" \n> > On Sun, 3 Jun 2018, Thomas Gummerer wrote:\n\n> >> --get-regex works as the parse-option API allows abbreviations of\n> >> the full option to be specified as long as the abbreviation is\n> >> unambiguos. I don't know if this is documented anywhere other\n> >> than 'Documentation/technical/api-parse-options.txt' though.\n>\n> it's in `git help cli`:\n>\n> many commands allow a long option --option to be abbreviated only to\n> their unique prefix (e.g. if there is no other option whose name\n> begins with opt, you may be able to spell --opt to invoke the\n> --option flag), but you should fully spell them out when writing\n> your scripts;\n>\n> It's a worthwile read, even if the man page isn't flagged up that\n> often.\n\n agreed that it's a good read and should be referenced more often.\none thing i don't see there, and it's based on an observation someone\nonce made (i believe on this list), is that even if there is\nabsolutely no ambiguity in a command, even if there are no pathspec\narguments, it's still worthwhile to add a trailing \"--\":\n\n $ git command options/treeish ... --\n\nsince that guarantees that git will waste no time trying to identify\nany ambiguity since you're being so precise. is that worth mentioning\nin that page?\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day Ottawa, Ontario, CANADA\n http://crashcourse.ca/dokuwiki\n\nTwitter: http://twitter.com/rpjday\nLinkedIn: http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"349239","messageId":"xmqq1sdm65hu.fsf@gitster-ct.c.googlers.com","threadId":"48634","inReplyTo":"alpine.LFD.2.21.1806040659590.11594@localhost.localdomain","subject":"Re: [PATCH v2] t/perf/run: Use proper \"--get-regexp\", not \"--get-regex\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-06-04T13:33:33Z","receivedAt":"2018-06-04T13:33:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert P. J. Day\" writes:\n\n> one thing i don't see there, and it's based on an observation someone\n> once made (i believe on this list), is that even if there is\n> absolutely no ambiguity in a command, even if there are no pathspec\n> arguments, it's still worthwhile to add a trailing \"--\":\n>\n> $ git command options/treeish ... --\n>\n> since that guarantees that git will waste no time trying to identify\n> any ambiguity since you're being so precise. is that worth mentioning\n> in that page?\n\nI do not think it is worth mentioning _anywhere_ if you sell its\nbenefit as \"even there is no ambiguity it won't spend cycles\". \n\nThe point of \"git cmd X --\" and \"git cmd -- X\" is that they save\nyour human cycle, not machine cycle; you do not have to waste time\nwondering if you happen to have X as path in the working tree. That\nmay be worth mentioning, but only \"maybe\" I would think.\n\nA more important reason is you may not _know_ beforehand if X you\nmean to be a rev also happens to be a path (or vice versa) when you\nare scripting. Writing 'git checkout master', 'git diff HEAD',\netc., in a script you intend to be generic enough is risky if\n'master', HEAD, etc. can be both rev and path at the same time, but\nthat is already described in gitcli page ;-)\n"}]}