{"thread":{"id":"31705","subject":"[ANNOUNCE] Git v1.8.0-rc0","startedAt":"2012-10-01T22:44:56Z","lastAt":"2012-10-05T19:07:59Z","messageCount":23,"participants":["Junio C Hamano","Michal Kiedrowicz","Jeff King","J Smith"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"200301","messageId":"7vwqz9ak2f.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":null,"subject":"[ANNOUNCE] Git v1.8.0-rc0","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-01T22:44:56Z","receivedAt":"2012-10-01T22:44:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A release candidate Git v1.8.0-rc0 is now available for testing at\nthe usual places. There are a couple of leftover features we might\nmerge before the final release, but other than that, this is meant\nto be more or less feature-complete preview of the upcoming 1.8.0.\n\nThe release tarballs are found at:\n\n http://code.google.com/p/git-core/downloads/list\n\nand their SHA-1 checksums are:\n\na5143163b9d17e1afd7e66d7c6e7457c2e09a022 git-1.8.0.rc0.tar.gz\n679891dad4b0168ddd618c1de05978e35189c1bf git-htmldocs-1.8.0.rc0.tar.gz\neab59abd44a941e382eca6ae5e1d357b337328d0 git-manpages-1.8.0.rc0.tar.gz\n\nAlso the following public repositories all have a copy of the v1.8.0-rc0\ntag and the master branch that the tag points at:\n\n url = git://repo.or.cz/alt-git.git\n url = https://code.google.com/p/git-core/\n url = git://git.sourceforge.jp/gitroot/git-core/git.git\n url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core\n url = https://github.com/gitster/git\n\nGit v1.8.0 Release Notes (draft)\n========================\n\nBackward compatibility notes\n----------------------------\n\nIn the next major release, we will change the behaviour of the \"git\npush\" command. When \"git push [$there]\" does not say what to push, we\nhave used the traditional \"matching\" semantics (all your branches were\nsent to the remote as long as there already are branches of the same\nname over there). We will use the \"simple\" semantics, that pushes the\ncurrent branch to the branch with the same name only when the current\nbranch is set to integrate with that remote branch. There is a user\npreference configuration variable \"push.default\" to change this, and\n\"git push\" will warn about the upcoming change until you set this\nvariable.\n\n\"git branch --set-upstream\" is deprecated and may be removed in a\nrelatively distant future. \"git branch [-u|--set-upstream-to]\" has\nbeen introduced with a saner order of arguments.\n\n\nUpdates since v1.7.12\n---------------------\n\nUI, Workflows & Features\n\n * A credential helper for Win32 to allow access to the keychain of\n the logged-in user has been added.\n\n * An initial port to HP NonStop.\n\n * A credential helper to allow access to the Gnome keyring has been\n added.\n\n * When \"git am\" sanitizes the Subject: line, we strip the prefix from\n \"Re: subject\" and also from a less common \"re: subject\", but left\n even less common \"RE: subject\" intact.\n\n * It was tempting to say \"git branch --set-upstream origin/master\",\n but that tells Git to arrange the local branch \"origin/master\" to\n integrate with the currently checked out branch, which is highly\n unlikely what the user meant. The option is deprecated; use the\n new \"--set-upstream-to\" (with a short-and-sweet \"-u\") option\n instead.\n\n * \"git cherry-pick\" learned the \"--allow-empty-message\" option to\n allow it to replay a commit without any log message.\n\n * After \"git cherry-pick -s\" gave control back to the user asking\n help to resolve conflicts, concluding \"git commit\" used to need to\n be run with \"-s\" if the user wants to sign it off; now the command\n leaves the sign-off line in the log template.\n\n * \"git daemon\" learned the \"--access-hook\" option to allow an\n external command to decline service based on the client address,\n repository path, etc.\n\n * \"git difftool --dir-diff\" learned to use symbolic links to prepare\n temporary copy of the working tree when available.\n\n * \"git grep\" learned to use a non-standard pattern type by default if\n a configuration variable tells it to.\n\n * \"git merge-base\" learned \"--is-ancestor A B\" option to tell if A is\n an ancestor of B. The result is indicated by its exit status code.\n\n * \"git mergetool\" allows users to override the actual command used\n with the mergetool.$name.cmd configuration variable even for built-in\n mergetool backends.\n\n * The \"-Xours\" backend option to \"git merge -s recursive\" now takes\n effect even on binary files.\n\n * \"git rebase -i\" learned the \"--edit-todo\" option to open an editor\n to edit the insn sheet.\n\n\nForeign Interface\n\n * \"git svn\" has been updated to work with SVN 1.7.\n\n * \"git p4\" learned \"--conflicts\" option to specify what to do when\n encountering a conflict during \"p4 submit\".\n\n\nPerformance, Internal Implementation, etc. (please report possible regressions)\n\n * Git ships with a fall-back regexp implementation for platforms with\n buggy regexp library, but it was easy for people to keep using their\n platform regexp. A new test has been added to check this.\n\n * The \"check-docs\" build target has been updated and greatly\n simplified.\n\n * The test suite is run under MALLOC_CHECK_ when running with glibc\n that supports the feature.\n\n * The documentation in the TeXinfo format was using indented output\n for materials meant to be examples that are better typeset in\n monospace.\n\n * Compatibility wrapper around some mkdir(2) implementations that\n reject parameter with trailing slash has been introduced.\n\n * Compatibility wrapper for systems that lack usable setitimer() has\n been added.\n\n * The option parsing of \"git checkout\" had error checking, dwim and\n defaulting missing options, all mixed in the code, and issuing an\n appropriate error message with useful context was getting harder.\n The code has been reorganized to allow giving a proper diagnosis\n when the user says \"git checkout -b -t foo bar\" (e.g. \"-t\" is not a\n good name for a branch).\n\n * Many internal uses of \"git merge-base\" equivalent were only to see\n if one commit fast-forwards to the other, which did not need the\n full set of merge bases to be computed. They have been updated to\n use less expensive checks.\n\n * The heuristics to detect and silently convert latin1 to utf8 when\n we were told to use utf-8 in the log message has been transplanted\n from \"mailinfo\" to \"commit\" and \"commit-tree\".\n\n * Messages given by \"git -h\" from many subcommands have\n been marked for translation.\n\n\nAlso contains minor documentation updates and code clean-ups.\n\n\nFixes since v1.7.12\n-------------------\n\nUnless otherwise noted, all the fixes since v1.7.12 in the\nmaintenance track are contained in this release (see release notes\nto them for details).\n\n * The attribute system may be asked for a path that itself or its\n leading directories no longer exists in the working tree, and it is\n fine if we cannot open .gitattribute file in such a case. Failure\n to open per-directory .gitattributes with error status other than\n ENOENT and ENOTDIR should be diagnosed, but it wasn't.\n\n * When looking for $HOME/.gitconfig etc., it is OK if we cannot read\n them because they do not exist, but we did not diagnose existing\n files that we cannot read.\n\n * When \"git am\" is fed an input that has multiple \"Content-type: ...\"\n header, it did not grok charset= attribute correctly.\n\n * \"git blame MAKEFILE\" run in a history that has \"Makefile\" but not\n \"MAKEFILE\" should say \"No such file MAKEFILE in HEAD\", but got\n confused on a case insensitive filesystem and failed to do so.\n\n * Even during a conflicted merge, \"git blame $path\" always meant to\n blame uncommitted changes to the \"working tree\" version; make it\n more useful by showing cleanly merged parts as coming from the other\n branch that is being merged.\n\n * It was unclear in the documentation for \"git blame\" that it is\n unnecessary for users to use the \"--follow\" option.\n (merge e5dce96 jc/blame-follows-renames later to maint).\n\n * Output from \"git branch -v\" contains \"(no branch)\" that could be\n localized, but the code to align it along with the names of\n branches were counting in bytes, not in display columns.\n\n * \"git cherry-pick A C B\" used to replay changes in A and then B and\n then C if these three commits had committer timestamps in that\n order, which is not what the user who said \"A C B\" naturally\n expects.\n\n * A repository created with \"git clone --single\" had its fetch\n refspecs set up just like a clone without \"--single\", leading the\n subsequent \"git fetch\" to slurp all the other branches, defeating\n the whole point of specifying \"only this branch\".\n (merge 31b808a rt/maint-clone-single later to maint).\n\n * Documentation talked about \"first line of commit log\" when it meant\n the title of the commit. The description was clarified by defining\n how the title is decided and rewording the casual mention of \"first\n line\" to \"title\".\n\n * \"git cvsimport\" did not thoroughly cleanse tag names that it\n inferred from the names of the tags it obtained from CVS, which\n caused \"git tag\" to barf and stop the import in the middle.\n\n * Earlier we made the diffstat summary line that shows the number of\n lines added/deleted localizable, but it was found irritating having\n to see them in various languages on a list whose discussion language\n is English.\n\n * \"git fetch --all\", when passed \"--no-tags\", did not honor the\n \"--no-tags\" option while fetching from individual remotes (the same\n issue existed with \"--tags\", but combination \"--all --tags\" makes\n much less sense than \"--all --no-tags\").\n\n * \"git fetch\" over http had an old workaround for an unlikely server\n misconfiguration; it turns out that this hurts debuggability of the\n configuration in general, and has been reverted.\n (merge 6ac964a sp/maint-http-info-refs-no-retry later to maint).\n\n * \"git fetch\" over http advertised that it supports \"deflate\", which\n is much less common, and did not advertise more common \"gzip\" on\n its Accept-Encoding header.\n (merge aa90b96 sp/maint-http-enable-gzip later to maint).\n\n * After \"gitk\" showed the contents of a tag, neither \"Reread\n references\" nor \"Reload\" did not update what is shown as the\n contents of it, when the user overwrote the tag with \"git tag -f\".\n\n * \"git log --all-match --grep=A --grep=B\" ought to show commits that\n mention both A and B, but when these three options are used with\n --author or --committer, it showed commits that mention either A or\n B (or both) instead.\n\n * \"git p4\", when \"--use-client-spec\" and \"--detect-branches\" are used\n together, misdetected branches.\n\n * \"git receive-pack\" (the counterpart to \"git push\") did not give\n progress output while processing objects it received to the puser\n when run over the smart-http protocol.\n (merge 74eb32d jk/receive-pack-unpack-error-to-pusher later to maint).\n\n * When you misspell the command name you give to the \"exec\" action in\n the \"git rebase -i\" insn sheet, you are told that 'rebase' is not a\n git subcommand from \"git rebase --continue\".\n\n * The subcommand in \"git remote\" to remove a defined remote was\n \"rm\" and the command did not take a fully-spelled \"remove\".\n\n * The interactive prompt \"git send-email\" gives was error prone. It\n asked \"What e-mail address do you want to use?\" with the address it\n guessed (correctly) the user would want to use in its prompt,\n tempting the user to say \"y\". But the response was taken as \"No,\n please use 'y' as the e-mail address instead\", which is most\n certainly not what the user meant.\n\n * \"git show --format='%ci'\" did not give timestamp correctly for\n commits created without human readable name on \"committer\" line.\n\n * \"git show --quiet\" ought to be a synonym for \"git show -s\", but\n wasn't.\n\n * \"git submodule frotz\" was not diagnosed as \"frotz\" being an unknown\n subcommand to \"git submodule\"; the user instead got a complaint\n that \"git submodule status\" was run with an unknown path \"frotz\".\n (merge af9c9f9 rr/maint-submodule-unknown-cmd later to maint).\n\n * \"git status\" honored the ignore=dirty settings in .gitmodules but\n \"git commit\" didn't.\n (merge 8f6811e os/commit-submodule-ignore later to maint).\n"},{"id":"200458","messageId":"7v626r48cv.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"7vwqz9ak2f.fsf@alter.siamese.dyndns.org","subject":"grep.patternType (was: Re: [ANNOUNCE] Git v1.8.0-rc0)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-03T20:18:56Z","receivedAt":"2012-10-03T20:18:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> * \"git grep\" learned to use a non-standard pattern type by default if\n> a configuration variable tells it to.\n\nThis addition makes\n\n git grep -e \"(integer|buffer)\"\n\nwork as expected, when grep.patternType is set to \"extended\".\n\nShould this\n\n git log --grep=\"(integer|buffer)\"\n\nalso honor the same configuration variable? If not, why not?\n\nOne more thing. Currently you can say\n\n git log -E --grep=\"(integer|buffer)\"\n\nto ask for the ERE. Should we also support -P to ask for pcre? If\nnot, why not?\n"},{"id":"200473","messageId":"7vmx032of1.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"7v626r48cv.fsf@alter.siamese.dyndns.org","subject":"Re: grep.patternType","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-03T22:14:58Z","receivedAt":"2012-10-03T22:14:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n>\n>> * \"git grep\" learned to use a non-standard pattern type by default if\n>> a configuration variable tells it to.\n>\n> This addition makes\n>\n> git grep -e \"(integer|buffer)\"\n>\n> work as expected, when grep.patternType is set to \"extended\".\n>\n> Should this\n>\n> git log --grep=\"(integer|buffer)\"\n>\n> also honor the same configuration variable? If not, why not?\n>\n> One more thing. Currently you can say\n>\n> git log -E --grep=\"(integer|buffer)\"\n>\n> to ask for the ERE. Should we also support -P to ask for pcre? If\n> not, why not?\n\nAnswering to myself who has been in tying-loose-ends mode.\n\nMy answers to these questions are both yes, and I have a neatly\nlined up series that begins with a small bugfix and then\nenhancement, but I do not think these do not deserve to in the\nupcoming release. The topic came too late, and even the fix is\nfor a bug that has been with us for a long time.\n"},{"id":"200478","messageId":"1349314419-8397-1-git-send-email-gitster@pobox.com","threadId":"31705","inReplyTo":"7v626r48cv.fsf@alter.siamese.dyndns.org","subject":"[PATCH 0/6] Tying loose ends of extended \"grep\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T01:33:33Z","receivedAt":"2012-10-04T01:33:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Over time we have added a few things to our \"git grep\" front-end,\nsuch as\n\n - grep.extendedregexp configuration (v1.7.5)\n - use of pcre (v1.7.6)\n - grep.patterntype configuration (v1.8.0)\n\nBut all the time, we forgot that \"git log --grep\" would need to\nhonor them.\n\nThe first three patches should be uncontroversial. We move helpers\nout of builtin/grep.c to a more generic place, and fix a bug in the\ncommand line parser for \"git log -F -E --grep=''\" (this did not\ncorrectly enable regular expression).\n\nThe fourth patch adds \"git log --perl-regexp --grep=''\".\n\nThe last two teaches \"log --grep\" to honor the same grep.*\nconfiguration variables.\n\ncolor.grep and grep.linenumber should not matter, as the use of grep\nmechanism in \"log --grep\" is about boolean result \"do we have hits?\"\nand not about actually showing the hits in the output, but the users\nwould expect that grep.extendedregexp and its more generalized\nversion grep.patterntype are honored, which was not the case.\n\nJunio C Hamano (6):\n grep: move configuration support to top-level grep.[ch]\n grep: move pattern-type bits support to top-level grep.[ch]\n log --grep: use the same helper to set -E/-F options as \"git grep\"\n log --grep: accept --basic-regexp and --perl-regexp\n log: pass rev_info to git_log_config()\n log --grep: honor grep.patterntype etc. configuration variables\n\n builtin/grep.c | 105 ++-------------------------------------------------------\n builtin/log.c | 19 +++++------\n grep.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++\n grep.h | 3 ++\n revision.c | 8 +++--\n t/t4202-log.sh | 6 ++++\n 6 files changed, 126 insertions(+), 114 deletions(-)\n\n-- \n1.8.0.rc0.57.g712528f\n"},{"id":"200486","messageId":"1349314419-8397-2-git-send-email-gitster@pobox.com","threadId":"31705","inReplyTo":"1349314419-8397-1-git-send-email-gitster@pobox.com","subject":"[PATCH 1/6] grep: move configuration support to top-level grep.[ch]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T01:33:34Z","receivedAt":"2012-10-04T01:33:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As \"git grep\" will not stay to be the only command that will know\nabout the grep machinery, move these to a more appropriate place.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/grep.c | 67 ----------------------------------------------------------\n grep.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n grep.h | 2 ++\n 3 files changed, 69 insertions(+), 67 deletions(-)\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex 82530a6..ce379d5 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -261,21 +261,6 @@ static int wait_all(void)\n }\n #endif\n \n-static int parse_pattern_type_arg(const char *opt, const char *arg)\n-{\n-\tif (!strcmp(arg, \"default\"))\n-\t\treturn GREP_PATTERN_TYPE_UNSPECIFIED;\n-\telse if (!strcmp(arg, \"basic\"))\n-\t\treturn GREP_PATTERN_TYPE_BRE;\n-\telse if (!strcmp(arg, \"extended\"))\n-\t\treturn GREP_PATTERN_TYPE_ERE;\n-\telse if (!strcmp(arg, \"fixed\"))\n-\t\treturn GREP_PATTERN_TYPE_FIXED;\n-\telse if (!strcmp(arg, \"perl\"))\n-\t\treturn GREP_PATTERN_TYPE_PCRE;\n-\tdie(\"bad %s argument: %s\", opt, arg);\n-}\n-\n static void grep_pattern_type_options(const int pattern_type, struct grep_opt *opt)\n {\n \tswitch (pattern_type) {\n@@ -308,58 +293,6 @@ static void grep_pattern_type_options(const int pattern_type, struct grep_opt *o\n \t}\n }\n \n-static int grep_config(const char *var, const char *value, void *cb)\n-{\n-\tstruct grep_opt *opt = cb;\n-\tchar *color = NULL;\n-\n-\tif (userdiff_config(var, value) < 0)\n-\t\treturn -1;\n-\n-\tif (!strcmp(var, \"grep.extendedregexp\")) {\n-\t\tif (git_config_bool(var, value))\n-\t\t\topt->extended_regexp_option = 1;\n-\t\telse\n-\t\t\topt->extended_regexp_option = 0;\n-\t\treturn 0;\n-\t}\n-\n-\tif (!strcmp(var, \"grep.patterntype\")) {\n-\t\topt->pattern_type_option = parse_pattern_type_arg(var, value);\n-\t\treturn 0;\n- }\n-\n-\tif (!strcmp(var, \"grep.linenumber\")) {\n-\t\topt->linenum = git_config_bool(var, value);\n-\t\treturn 0;\n-\t}\n-\n-\tif (!strcmp(var, \"color.grep\"))\n-\t\topt->color = git_config_colorbool(var, value);\n-\telse if (!strcmp(var, \"color.grep.context\"))\n-\t\tcolor = opt->color_context;\n-\telse if (!strcmp(var, \"color.grep.filename\"))\n-\t\tcolor = opt->color_filename;\n-\telse if (!strcmp(var, \"color.grep.function\"))\n-\t\tcolor = opt->color_function;\n-\telse if (!strcmp(var, \"color.grep.linenumber\"))\n-\t\tcolor = opt->color_lineno;\n-\telse if (!strcmp(var, \"color.grep.match\"))\n-\t\tcolor = opt->color_match;\n-\telse if (!strcmp(var, \"color.grep.selected\"))\n-\t\tcolor = opt->color_selected;\n-\telse if (!strcmp(var, \"color.grep.separator\"))\n-\t\tcolor = opt->color_sep;\n-\telse\n-\t\treturn git_color_default_config(var, value, cb);\n-\tif (color) {\n-\t\tif (!value)\n-\t\t\treturn config_error_nonbool(var);\n-\t\tcolor_parse(value, var, color);\n-\t}\n-\treturn 0;\n-}\n-\n static void *lock_and_read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size)\n {\n \tvoid *data;\ndiff --git a/grep.c b/grep.c\nindex edc7776..551a2ed 100644\n--- a/grep.c\n+++ b/grep.c\n@@ -1518,3 +1518,70 @@ static int grep_source_is_binary(struct grep_source *gs)\n \n \treturn 0;\n }\n+\n+static int parse_pattern_type_arg(const char *opt, const char *arg)\n+{\n+\tif (!strcmp(arg, \"default\"))\n+\t\treturn GREP_PATTERN_TYPE_UNSPECIFIED;\n+\telse if (!strcmp(arg, \"basic\"))\n+\t\treturn GREP_PATTERN_TYPE_BRE;\n+\telse if (!strcmp(arg, \"extended\"))\n+\t\treturn GREP_PATTERN_TYPE_ERE;\n+\telse if (!strcmp(arg, \"fixed\"))\n+\t\treturn GREP_PATTERN_TYPE_FIXED;\n+\telse if (!strcmp(arg, \"perl\"))\n+\t\treturn GREP_PATTERN_TYPE_PCRE;\n+\tdie(\"bad %s argument: %s\", opt, arg);\n+}\n+\n+int grep_config(const char *var, const char *value, void *cb)\n+{\n+\tstruct grep_opt *opt = cb;\n+\tchar *color = NULL;\n+\n+\tif (userdiff_config(var, value) < 0)\n+\t\treturn -1;\n+\n+\tif (!strcmp(var, \"grep.extendedregexp\")) {\n+\t\tif (git_config_bool(var, value))\n+\t\t\topt->extended_regexp_option = 1;\n+\t\telse\n+\t\t\topt->extended_regexp_option = 0;\n+\t\treturn 0;\n+\t}\n+\n+\tif (!strcmp(var, \"grep.patterntype\")) {\n+\t\topt->pattern_type_option = parse_pattern_type_arg(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\tif (!strcmp(var, \"grep.linenumber\")) {\n+\t\topt->linenum = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\tif (!strcmp(var, \"color.grep\"))\n+\t\topt->color = git_config_colorbool(var, value);\n+\telse if (!strcmp(var, \"color.grep.context\"))\n+\t\tcolor = opt->color_context;\n+\telse if (!strcmp(var, \"color.grep.filename\"))\n+\t\tcolor = opt->color_filename;\n+\telse if (!strcmp(var, \"color.grep.function\"))\n+\t\tcolor = opt->color_function;\n+\telse if (!strcmp(var, \"color.grep.linenumber\"))\n+\t\tcolor = opt->color_lineno;\n+\telse if (!strcmp(var, \"color.grep.match\"))\n+\t\tcolor = opt->color_match;\n+\telse if (!strcmp(var, \"color.grep.selected\"))\n+\t\tcolor = opt->color_selected;\n+\telse if (!strcmp(var, \"color.grep.separator\"))\n+\t\tcolor = opt->color_sep;\n+\telse\n+\t\treturn git_color_default_config(var, value, cb);\n+\tif (color) {\n+\t\tif (!value)\n+\t\t\treturn config_error_nonbool(var);\n+\t\tcolor_parse(value, var, color);\n+\t}\n+\treturn 0;\n+}\ndiff --git a/grep.h b/grep.h\nindex c256ac6..5381adc 100644\n--- a/grep.h\n+++ b/grep.h\n@@ -145,6 +145,8 @@ extern void compile_grep_patterns(struct grep_opt *opt);\n extern void free_grep_patterns(struct grep_opt *opt);\n extern int grep_buffer(struct grep_opt *opt, char *buf, unsigned long size);\n \n+int grep_config(const char *var, const char *value, void *cb);\n+\n struct grep_source {\n \tchar *name;\n \n-- \n1.8.0.rc0.57.g712528f\n"},{"id":"200467","messageId":"1349314419-8397-3-git-send-email-gitster@pobox.com","threadId":"31705","inReplyTo":"1349314419-8397-1-git-send-email-gitster@pobox.com","subject":"[PATCH 2/6] grep: move pattern-type bits support to top-level grep.[ch]","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T01:33:35Z","receivedAt":"2012-10-04T01:33:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Switching between -E/-G/-P/-F correctly needs a lot more than just\nflipping opt->regflags bit these days, and we have a nice helper\nfunction buried in builtin/grep.c for the sole use of \"git grep\".\n\nExtract it so that \"log --grep\" family can also use it.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/grep.c | 38 +++-----------------------------------\n grep.c | 32 ++++++++++++++++++++++++++++++++\n grep.h | 1 +\n 3 files changed, 36 insertions(+), 35 deletions(-)\n\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex ce379d5..2b14fee 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -261,38 +261,6 @@ static int wait_all(void)\n }\n #endif\n \n-static void grep_pattern_type_options(const int pattern_type, struct grep_opt *opt)\n-{\n-\tswitch (pattern_type) {\n-\tcase GREP_PATTERN_TYPE_UNSPECIFIED:\n-\t\t/* fall through */\n-\n-\tcase GREP_PATTERN_TYPE_BRE:\n-\t\topt->fixed = 0;\n-\t\topt->pcre = 0;\n-\t\topt->regflags &= ~REG_EXTENDED;\n-\t\tbreak;\n-\n-\tcase GREP_PATTERN_TYPE_ERE:\n-\t\topt->fixed = 0;\n-\t\topt->pcre = 0;\n-\t\topt->regflags |= REG_EXTENDED;\n-\t\tbreak;\n-\n-\tcase GREP_PATTERN_TYPE_FIXED:\n-\t\topt->fixed = 1;\n-\t\topt->pcre = 0;\n-\t\topt->regflags &= ~REG_EXTENDED;\n-\t\tbreak;\n-\n-\tcase GREP_PATTERN_TYPE_PCRE:\n-\t\topt->fixed = 0;\n-\t\topt->pcre = 1;\n-\t\topt->regflags &= ~REG_EXTENDED;\n-\t\tbreak;\n-\t}\n-}\n-\n static void *lock_and_read_sha1_file(const unsigned char *sha1, enum object_type *type, unsigned long *size)\n {\n \tvoid *data;\n@@ -810,11 +778,11 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\t\t PARSE_OPT_NO_INTERNAL_HELP);\n \n \tif (pattern_type_arg != GREP_PATTERN_TYPE_UNSPECIFIED)\n-\t\tgrep_pattern_type_options(pattern_type_arg, &opt);\n+\t\tgrep_set_pattern_type_option(pattern_type_arg, &opt);\n \telse if (opt.pattern_type_option != GREP_PATTERN_TYPE_UNSPECIFIED)\n-\t\tgrep_pattern_type_options(opt.pattern_type_option, &opt);\n+\t\tgrep_set_pattern_type_option(opt.pattern_type_option, &opt);\n \telse if (opt.extended_regexp_option)\n-\t\tgrep_pattern_type_options(GREP_PATTERN_TYPE_ERE, &opt);\n+\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE, &opt);\n \n \tif (use_index && !startup_info->have_repository)\n \t\t/* die the same way as if we did it at the beginning */\ndiff --git a/grep.c b/grep.c\nindex 551a2ed..0d8df65 100644\n--- a/grep.c\n+++ b/grep.c\n@@ -1585,3 +1585,35 @@ int grep_config(const char *var, const char *value, void *cb)\n \t}\n \treturn 0;\n }\n+\n+void grep_set_pattern_type_option(enum grep_pattern_type pattern_type, struct grep_opt *opt)\n+{\n+\tswitch (pattern_type) {\n+\tcase GREP_PATTERN_TYPE_UNSPECIFIED:\n+\t\t/* fall through */\n+\n+\tcase GREP_PATTERN_TYPE_BRE:\n+\t\topt->fixed = 0;\n+\t\topt->pcre = 0;\n+\t\topt->regflags &= ~REG_EXTENDED;\n+\t\tbreak;\n+\n+\tcase GREP_PATTERN_TYPE_ERE:\n+\t\topt->fixed = 0;\n+\t\topt->pcre = 0;\n+\t\topt->regflags |= REG_EXTENDED;\n+\t\tbreak;\n+\n+\tcase GREP_PATTERN_TYPE_FIXED:\n+\t\topt->fixed = 1;\n+\t\topt->pcre = 0;\n+\t\topt->regflags &= ~REG_EXTENDED;\n+\t\tbreak;\n+\n+\tcase GREP_PATTERN_TYPE_PCRE:\n+\t\topt->fixed = 0;\n+\t\topt->pcre = 1;\n+\t\topt->regflags &= ~REG_EXTENDED;\n+\t\tbreak;\n+\t}\n+}\ndiff --git a/grep.h b/grep.h\nindex 5381adc..2f6aaa5 100644\n--- a/grep.h\n+++ b/grep.h\n@@ -145,6 +145,7 @@ extern void compile_grep_patterns(struct grep_opt *opt);\n extern void free_grep_patterns(struct grep_opt *opt);\n extern int grep_buffer(struct grep_opt *opt, char *buf, unsigned long size);\n \n+void grep_set_pattern_type_option(enum grep_pattern_type, struct grep_opt *opt);\n int grep_config(const char *var, const char *value, void *cb);\n \n struct grep_source {\n-- \n1.8.0.rc0.57.g712528f\n"},{"id":"200474","messageId":"1349314419-8397-4-git-send-email-gitster@pobox.com","threadId":"31705","inReplyTo":"1349314419-8397-1-git-send-email-gitster@pobox.com","subject":"[PATCH 3/6] log --grep: use the same helper to set -E/-F options as \"git grep\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T01:33:36Z","receivedAt":"2012-10-04T01:33:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The command line option parser for \"git log -F -E --grep=''\"\ndid not flip the \"fixed\" bit, violating the general \"last option\nwins\" principle among conflicting options.\n\nSigned-off-by: Junio C Hamano \n---\n revision.c | 4 ++--\n t/t4202-log.sh | 6 ++++++\n 2 files changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex a09e60b..7f5e53b 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1604,12 +1604,12 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t} else if (!strcmp(arg, \"--grep-debug\")) {\n \t\trevs->grep_filter.debug = 1;\n \t} else if (!strcmp(arg, \"--extended-regexp\") || !strcmp(arg, \"-E\")) {\n-\t\trevs->grep_filter.regflags |= REG_EXTENDED;\n+\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE, &revs->grep_filter);\n \t} else if (!strcmp(arg, \"--regexp-ignore-case\") || !strcmp(arg, \"-i\")) {\n \t\trevs->grep_filter.regflags |= REG_ICASE;\n \t\tDIFF_OPT_SET(&revs->diffopt, PICKAXE_IGNORE_CASE);\n \t} else if (!strcmp(arg, \"--fixed-strings\") || !strcmp(arg, \"-F\")) {\n-\t\trevs->grep_filter.fixed = 1;\n+\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_FIXED, &revs->grep_filter);\n \t} else if (!strcmp(arg, \"--all-match\")) {\n \t\trevs->grep_filter.all_match = 1;\n \t} else if ((argcount = parse_long_opt(\"encoding\", argv, &optarg))) {\ndiff --git a/t/t4202-log.sh b/t/t4202-log.sh\nindex 924ba53..e6537ab 100755\n--- a/t/t4202-log.sh\n+++ b/t/t4202-log.sh\n@@ -230,6 +230,12 @@ test_expect_success 'log --grep -i' '\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'log -F -E --grep= uses ere' '\n+\techo second >expect &&\n+\tgit log -1 --pretty=\"tformat:%s\" -F -E --grep=s.c.nd >actual &&\n+\ttest_cmp expect actual\n+'\n+\n cat > expect <\n---\n revision.c | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/revision.c b/revision.c\nindex 7f5e53b..0f73512 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1603,6 +1603,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t\treturn argcount;\n \t} else if (!strcmp(arg, \"--grep-debug\")) {\n \t\trevs->grep_filter.debug = 1;\n+\t} else if (!strcmp(arg, \"--basic-regexp\")) {\n+\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_BRE, &revs->grep_filter);\n \t} else if (!strcmp(arg, \"--extended-regexp\") || !strcmp(arg, \"-E\")) {\n \t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE, &revs->grep_filter);\n \t} else if (!strcmp(arg, \"--regexp-ignore-case\") || !strcmp(arg, \"-i\")) {\n@@ -1610,6 +1612,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t\tDIFF_OPT_SET(&revs->diffopt, PICKAXE_IGNORE_CASE);\n \t} else if (!strcmp(arg, \"--fixed-strings\") || !strcmp(arg, \"-F\")) {\n \t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_FIXED, &revs->grep_filter);\n+\t} else if (!strcmp(arg, \"--perl-regexp\") || !strcmp(arg, \"-P\")) {\n+\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE, &revs->grep_filter);\n \t} else if (!strcmp(arg, \"--all-match\")) {\n \t\trevs->grep_filter.all_match = 1;\n \t} else if ((argcount = parse_long_opt(\"encoding\", argv, &optarg))) {\n-- \n1.8.0.rc0.57.g712528f\n"},{"id":"200482","messageId":"1349314419-8397-6-git-send-email-gitster@pobox.com","threadId":"31705","inReplyTo":"1349314419-8397-1-git-send-email-gitster@pobox.com","subject":"[PATCH 5/6] log: pass rev_info to git_log_config()","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T01:33:38Z","receivedAt":"2012-10-04T01:33:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Call init_revisions() first to prepare the revision traversal\nparameters and pass it to git_log_config(), so that necessary bits\nin the traversal parameters can be tweaked before we call the\ncommand line parsing infrastructure setup_revisions() from\nthe cmd_log_init_finish() function.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This is made separate from the next one that touches the contents\n of \"rev\" to make sure the existing code does not depend on the\n current initialization order. I do not think it does but better\n be careful to keep the history easier to bisect, than be sorry\n when an issue does appear.\n\n builtin/log.c | 14 +++++---------\n 1 file changed, 5 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/log.c b/builtin/log.c\nindex 09cf43e..07a0078 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -360,9 +360,8 @@ int cmd_whatchanged(int argc, const char **argv, const char *prefix)\n \tstruct rev_info rev;\n \tstruct setup_revision_opt opt;\n \n-\tgit_config(git_log_config, NULL);\n-\n \tinit_revisions(&rev, prefix);\n+\tgit_config(git_log_config, &rev);\n \trev.diff = 1;\n \trev.simplify_history = 0;\n \tmemset(&opt, 0, sizeof(opt));\n@@ -450,10 +449,9 @@ int cmd_show(int argc, const char **argv, const char *prefix)\n \tstruct pathspec match_all;\n \tint i, count, ret = 0;\n \n-\tgit_config(git_log_config, NULL);\n-\n \tinit_pathspec(&match_all, NULL);\n \tinit_revisions(&rev, prefix);\n+\tgit_config(git_log_config, &rev);\n \trev.diff = 1;\n \trev.always_show_header = 1;\n \trev.no_walk = REVISION_WALK_NO_WALK_SORTED;\n@@ -530,9 +528,8 @@ int cmd_log_reflog(int argc, const char **argv, const char *prefix)\n \tstruct rev_info rev;\n \tstruct setup_revision_opt opt;\n \n-\tgit_config(git_log_config, NULL);\n-\n \tinit_revisions(&rev, prefix);\n+\tgit_config(git_log_config, &rev);\n \tinit_reflog_walk(&rev.reflog_info);\n \trev.verbose_header = 1;\n \tmemset(&opt, 0, sizeof(opt));\n@@ -552,9 +549,8 @@ int cmd_log(int argc, const char **argv, const char *prefix)\n \tstruct rev_info rev;\n \tstruct setup_revision_opt opt;\n \n-\tgit_config(git_log_config, NULL);\n-\n \tinit_revisions(&rev, prefix);\n+\tgit_config(git_log_config, &rev);\n \trev.always_show_header = 1;\n \tmemset(&opt, 0, sizeof(opt));\n \topt.def = \"HEAD\";\n@@ -1121,8 +1117,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \textra_hdr.strdup_strings = 1;\n \textra_to.strdup_strings = 1;\n \textra_cc.strdup_strings = 1;\n-\tgit_config(git_format_config, NULL);\n \tinit_revisions(&rev, prefix);\n+\tgit_config(git_format_config, &rev);\n \trev.commit_format = CMIT_FMT_EMAIL;\n \trev.verbose_header = 1;\n \trev.diff = 1;\n-- \n1.8.0.rc0.57.g712528f\n"},{"id":"200462","messageId":"1349314419-8397-7-git-send-email-gitster@pobox.com","threadId":"31705","inReplyTo":"1349314419-8397-1-git-send-email-gitster@pobox.com","subject":"[PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T01:33:39Z","receivedAt":"2012-10-04T01:33:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Read grep.extendedregexp, grep.patterntype, etc. from the\nconfiguration so that \"log --grep=''\" honors the user\npreference without an explicit -P from the command line.\n\nNow that the callback parameter, which was so far unused, to\ngit_log_config() has to be of type \"struct rev_info *\", stop passing\nit down to git_diff_ui_config(). The latter does not currently take\nany callback parameter, and when it does, we would need to make a\nstructure that has rev info and that parameter and pass it to\ngit_log_config() anyway, and until that happens, passing NULL will\nbe less error prone.\n\nSigned-off-by: Junio C Hamano \n---\n builtin/log.c | 5 ++++-\n 1 file changed, 4 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/log.c b/builtin/log.c\nindex 07a0078..a38a6dd 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -329,6 +329,8 @@ static int cmd_log_walk(struct rev_info *rev)\n \n static int git_log_config(const char *var, const char *value, void *cb)\n {\n+\tstruct rev_info *revs = cb;\n+\n \tif (!strcmp(var, \"format.pretty\"))\n \t\treturn git_config_string(&fmt_pretty, var, value);\n \tif (!strcmp(var, \"format.subjectprefix\"))\n@@ -352,7 +354,8 @@ static int git_log_config(const char *var, const char *value, void *cb)\n \tif (!prefixcmp(var, \"color.decorate.\"))\n \t\treturn parse_decorate_color_config(var, 15, value);\n \n-\treturn git_diff_ui_config(var, value, cb);\n+\tgrep_config(var, value, &revs->grep_filter);\n+\treturn git_diff_ui_config(var, value, NULL);\n }\n \n int cmd_whatchanged(int argc, const char **argv, const char *prefix)\n-- \n1.8.0.rc0.57.g712528f\n"},{"id":"200472","messageId":"20121004080543.3b31280f@mkiedrowicz","threadId":"31705","inReplyTo":"7vmx032of1.fsf@alter.siamese.dyndns.org","subject":"Re: grep.patternType","fromName":"Michal Kiedrowicz","fromEmail":"michal.kiedrowicz@gmail.com","sentAt":"2012-10-04T06:05:43Z","receivedAt":"2012-10-04T06:05:43Z","isPatch":false,"sender":{"key":"michal.kiedrowicz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14072847?v=4"},"body":"Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > Junio C Hamano writes:\n> >\n> >> * \"git grep\" learned to use a non-standard pattern type by\n> >> default if a configuration variable tells it to.\n> >\n> > This addition makes\n> >\n> > git grep -e \"(integer|buffer)\"\n> >\n> > work as expected, when grep.patternType is set to \"extended\".\n> >\n> > Should this\n> >\n> > git log --grep=\"(integer|buffer)\"\n> >\n> > also honor the same configuration variable? If not, why not?\n\nI think this should respect grep.patternType.\n\n> >\n> > One more thing. Currently you can say\n> >\n> > git log -E --grep=\"(integer|buffer)\"\n> >\n> > to ask for the ERE. Should we also support -P to ask for pcre? If\n> > not, why not?\n\nThis also.\n\n> \n> Answering to myself who has been in tying-loose-ends mode.\n> \n> My answers to these questions are both yes, and I have a neatly\n> lined up series that begins with a small bugfix and then\n> enhancement, but I do not think these do not deserve to in the\n> upcoming release. The topic came too late, and even the fix is\n> for a bug that has been with us for a long time.\n\nI think I am the one to blame for this inconsistency. When I\nimplemented \"git-grep -P\" I was thinking about making it work for all\nregex operations in git but since I'm mostly using regexes with\ngit-grep I was too lazy to make it work with git-log.\n"},{"id":"200526","messageId":"7v1uhe3efa.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"1349314419-8397-6-git-send-email-gitster@pobox.com","subject":"Re: [PATCH 5/6] log: pass rev_info to git_log_config()","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T07:05:29Z","receivedAt":"2012-10-04T07:05:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Call init_revisions() first to prepare the revision traversal\n> parameters and pass it to git_log_config(), so that necessary bits\n> in the traversal parameters can be tweaked before we call the\n> command line parsing infrastructure setup_revisions() from\n> the cmd_log_init_finish() function.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n>\n> * This is made separate from the next one that touches the contents\n> of \"rev\" to make sure the existing code does not depend on the\n> current initialization order. I do not think it does but better\n> be careful to keep the history easier to bisect, than be sorry\n> when an issue does appear.\n\nAnd I was right X-<. This does break the assumption the recent\ndiff.context series makes.\n\nWhat happens is that\n\n - init_revisions() initializes revs->grep_filter; that is why this\n patch wanted to call it first, so that it can futz with it\n from git_config().\n\n - however, init_revisions() also calls diff_setup(), and the\n diff machinery initializes revs->diffopt->context from\n diff_context_default. Compiled in default of this value is 3,\n but the diff.context series wants to update this variable with\n the configuration before this call happens.\n\nSo we would need to do something like:\n\n - call git_log_config() first to let diff_context_default\n updated from the configuration as before. find the values of\n grep.* defaults at the same time, but stash it away in a\n separate \"struct grep_opt\" (yuck);\n\n - call init_revisions() and let it initialize revs->grep_filter\n and revs->diffopt as before;\n\n - copy the grep.* defaults we learned during git_log_config() to\n revs->grep_filter.\n\nwhich is a bit yucky, but survivable.\n\nI'll fix these two patches up later.\n"},{"id":"200488","messageId":"20121004080947.GB31305@sigill.intra.peff.net","threadId":"31705","inReplyTo":"1349314419-8397-4-git-send-email-gitster@pobox.com","subject":"Re: [PATCH 3/6] log --grep: use the same helper to set -E/-F options as \"git grep\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-04T08:09:47Z","receivedAt":"2012-10-04T08:09:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 03, 2012 at 06:33:36PM -0700, Junio C Hamano wrote:\n\n> diff --git a/revision.c b/revision.c\n> index a09e60b..7f5e53b 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -1604,12 +1604,12 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n> \t} else if (!strcmp(arg, \"--grep-debug\")) {\n> \t\trevs->grep_filter.debug = 1;\n> \t} else if (!strcmp(arg, \"--extended-regexp\") || !strcmp(arg, \"-E\")) {\n> -\t\trevs->grep_filter.regflags |= REG_EXTENDED;\n> +\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_ERE, &revs->grep_filter);\n> \t} else if (!strcmp(arg, \"--regexp-ignore-case\") || !strcmp(arg, \"-i\")) {\n> \t\trevs->grep_filter.regflags |= REG_ICASE;\n> \t\tDIFF_OPT_SET(&revs->diffopt, PICKAXE_IGNORE_CASE);\n> \t} else if (!strcmp(arg, \"--fixed-strings\") || !strcmp(arg, \"-F\")) {\n> -\t\trevs->grep_filter.fixed = 1;\n> +\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_FIXED, &revs->grep_filter);\n\nVery nice. After seeing the discussion on regexp types in your G+ feed,\nI took a 5-minute look at this code last night and noticed the same\noddity. At which point I gave up looking at it for the evening, thinking\nto come back to it later. And here my procrastination is rewarded. :)\n\n-Peff\n"},{"id":"200528","messageId":"20121004081212.GC31305@sigill.intra.peff.net","threadId":"31705","inReplyTo":"1349314419-8397-5-git-send-email-gitster@pobox.com","subject":"Re: [PATCH 4/6] log --grep: accept --basic-regexp and --perl-regexp","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-04T08:12:12Z","receivedAt":"2012-10-04T08:12:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 03, 2012 at 06:33:37PM -0700, Junio C Hamano wrote:\n\n> When we added the \"--perl-regexp\" option (or \"-P\") to \"git grep\", we\n> should have done the same for the commands in the \"git log\" family,\n> but somehow we forgot to do so. This corrects it.\n> \n> Also introduce the \"--basic-regexp\" option for completeness, so that\n> the \"last one wins\" principle can be used to defeat an earlier -E\n> option, e.g. \"git log -E --basic-regexp --grep=''\". Note that\n> it cannot have the short \"-G\" option as the option is to grep in the\n> patch text in the context of \"log\" family.\n\nGood, I think the addition of --basic-regexp is a nice touch.\n\n> +\t} else if (!strcmp(arg, \"--perl-regexp\") || !strcmp(arg, \"-P\")) {\n> +\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE, &revs->grep_filter);\n\nDo we want to yield short-and-sweet \"-P\" to perl-regexp? git-grep does\nso to match GNU grep, but we are not matching anything here (except\nourselves in git-grep). I'd think most people who use it regularly would\njust set grep.patternType.\n\nI could go either way, though.\n\n-Peff\n"},{"id":"200495","messageId":"20121004081732.GD31305@sigill.intra.peff.net","threadId":"31705","inReplyTo":"1349314419-8397-7-git-send-email-gitster@pobox.com","subject":"Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-04T08:17:32Z","receivedAt":"2012-10-04T08:17:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 03, 2012 at 06:33:39PM -0700, Junio C Hamano wrote:\n\n> Read grep.extendedregexp, grep.patterntype, etc. from the\n> configuration so that \"log --grep=''\" honors the user\n> preference without an explicit -P from the command line.\n> \n> Now that the callback parameter, which was so far unused, to\n> git_log_config() has to be of type \"struct rev_info *\", stop passing\n> it down to git_diff_ui_config(). The latter does not currently take\n> any callback parameter, and when it does, we would need to make a\n> structure that has rev info and that parameter and pass it to\n> git_log_config() anyway, and until that happens, passing NULL will\n> be less error prone.\n\nHmm. So I think this is a nice feature for some people, but I wonder if\nwe would run into any plumbing compatibility issues. People do tend to\nuse \"log\" as plumbing (since rev-list is not as capable). On the other\nhand, I'd think most internal uses of \"log --grep\" would be passing\nsomething along from the user, and the user would be happy to have it\ninterpreted by their chosen set of rules.\n\n-Peff\n"},{"id":"200540","messageId":"7vk3v6191h.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"20121004081212.GC31305@sigill.intra.peff.net","subject":"Re: [PATCH 4/6] log --grep: accept --basic-regexp and --perl-regexp","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T16:44:42Z","receivedAt":"2012-10-04T16:44:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> +\t} else if (!strcmp(arg, \"--perl-regexp\") || !strcmp(arg, \"-P\")) {\n>> +\t\tgrep_set_pattern_type_option(GREP_PATTERN_TYPE_PCRE, &revs->grep_filter);\n>\n> Do we want to yield short-and-sweet \"-P\" to perl-regexp? git-grep does\n> so to match GNU grep, but we are not matching anything here (except\n> ourselves in git-grep). I'd think most people who use it regularly would\n> just set grep.patternType.\n\nMy instinct always is that we should not to add short-and-sweet one\nletter option until it is known to be necessary and useful; the\nabove was me typing without thinkng. And I agree grep.patternType\nshould be sufficient.\n"},{"id":"200512","messageId":"7vehle18y5.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"20121004081732.GD31305@sigill.intra.peff.net","subject":"Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T16:46:42Z","receivedAt":"2012-10-04T16:46:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Hmm. So I think this is a nice feature for some people, but I wonder if\n> we would run into any plumbing compatibility issues. People do tend to\n> use \"log\" as plumbing (since rev-list is not as capable). On the other\n> hand, I'd think most internal uses of \"log --grep\" would be passing\n> something along from the user, and the user would be happy to have it\n> interpreted by their chosen set of rules.\n\nThis does make \"rev-list --grep\" aware of the configuration but at\nthe same time --basic-regexp and friends are also available to it.\n"},{"id":"200535","messageId":"20121004180122.GB2623@sigill.intra.peff.net","threadId":"31705","inReplyTo":"7vehle18y5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-04T18:01:22Z","receivedAt":"2012-10-04T18:01:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Hmm. So I think this is a nice feature for some people, but I wonder if\n> > we would run into any plumbing compatibility issues. People do tend to\n> > use \"log\" as plumbing (since rev-list is not as capable). On the other\n> > hand, I'd think most internal uses of \"log --grep\" would be passing\n> > something along from the user, and the user would be happy to have it\n> > interpreted by their chosen set of rules.\n> \n> This does make \"rev-list --grep\" aware of the configuration but at\n> the same time --basic-regexp and friends are also available to it.\n\nDoes it? I thought the patch only tweaked git_log_config. Am I\nmisreading?\n\nHaving --basic-regexp is a nice escape hatch, but it would be a\nregression for older scripts which were written before --basic-regexp\nexisted (or was necessary).\n\n-Peff\n"},{"id":"200530","messageId":"7v7gr6yryc.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"20121004180122.GB2623@sigill.intra.peff.net","subject":"Re: [PATCH 6/6] log --grep: honor grep.patterntype etc. configuration variables","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-04T19:09:47Z","receivedAt":"2012-10-04T19:09:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Oct 04, 2012 at 09:46:42AM -0700, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > Hmm. So I think this is a nice feature for some people, but I wonder if\n>> > we would run into any plumbing compatibility issues. People do tend to\n>> > use \"log\" as plumbing (since rev-list is not as capable). On the other\n>> > hand, I'd think most internal uses of \"log --grep\" would be passing\n>> > something along from the user, and the user would be happy to have it\n>> > interpreted by their chosen set of rules.\n>> \n>> This does make \"rev-list --grep\" aware of the configuration but at\n>> the same time --basic-regexp and friends are also available to it.\n>\n> Does it?\n\nAh, it doesn't.\n\nYou can still say \"rev-list --perl-regexp --grep=pcre\" but that is\nnot what 6/6 does.\n"},{"id":"200593","messageId":"7vk3v5v9ip.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"7v1uhe3efa.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] log: pass rev_info to git_log_config()","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-05T04:16:14Z","receivedAt":"2012-10-05T04:16:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> So we would need to do something like:\n>\n> - call git_log_config() first to let diff_context_default\n> updated from the configuration as before. find the values of\n> grep.* defaults at the same time, but stash it away in a\n> separate \"struct grep_opt\" (yuck);\n>\n> - call init_revisions() and let it initialize revs->grep_filter\n> and revs->diffopt as before;\n>\n> - copy the grep.* defaults we learned during git_log_config() to\n> revs->grep_filter.\n>\n> which is a bit yucky, but survivable.\n\nAfter thinking about it a bit more, I came to a conclusion that the\nconfiguration handling lifted from builtin/grep.c needs a much\nlarger overhaul.\n\nThe grep_config() function takes one instance of grep_opt as a\ncallback parameter, and populates it by running git_config(). This\nhas three practical implications.\n\n - You have to have an instance of grep_opt already when you call\n the configuration. The codepath under discussion in this thread\n is a prime example why that arrangement is not always possible.\n\n - It is not easy to enhance grep_config() in such a way to make it\n cascade to other callback functions to grab other variables in\n one call of git_config(); grep_config() can be cascaded into from\n other callbacks, but it has to be at the leaf level of a cascade.\n\n - If you ever need to use more than one instance of grep_opt, you\n will have to open and read the configuration file(s) every time\n you initialize them.\n\nThe right way to arrange your configuration callback is probably to\nmodel it after how diff configuration variables are handled. You\ncall git_config() once, and remember the values you read in set of\nstatic variables. Later, whenever you need to instantiate a grep_opt,\nyou initialize it from these static variables.\n\nAll of the above did not matter back when the code in builtin/grep.c\nwas isolated and the configuration was never meant to be used by\nother subsystems. But the last two patches in this series do want\nto break that assumption, so grep_config() needs to be rethought.\n\nLuckily, we don't have to have this in the upcoming 1.8.0 release\n(it is is too late for any topic that is not a regression fix).\n"},{"id":"200600","messageId":"CADFUPgfkm9kAFguodP1N23B2GHNbCQ86bu=s6rZ0eH0T4inmOQ@mail.gmail.com","threadId":"31705","inReplyTo":"7vmx032of1.fsf@alter.siamese.dyndns.org","subject":"Re: grep.patternType","fromName":"J Smith","fromEmail":"dark.panda@gmail.com","sentAt":"2012-10-05T05:38:15Z","receivedAt":"2012-10-05T05:38:15Z","isPatch":false,"sender":{"key":"dark.panda@gmail.com","avatar":"https://avatars.githubusercontent.com/u/84783?v=4"},"body":"On Wed, Oct 3, 2012 at 6:14 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> * \"git grep\" learned to use a non-standard pattern type by default if\n>>> a configuration variable tells it to.\n>>\n>> This addition makes\n>>\n>> git grep -e \"(integer|buffer)\"\n>>\n>> work as expected, when grep.patternType is set to \"extended\".\n>>\n>> Should this\n>>\n>> git log --grep=\"(integer|buffer)\"\n>>\n>> also honor the same configuration variable? If not, why not?\n>>\n>> One more thing. Currently you can say\n>>\n>> git log -E --grep=\"(integer|buffer)\"\n>>\n>> to ask for the ERE. Should we also support -P to ask for pcre? If\n>> not, why not?\n>\n> Answering to myself who has been in tying-loose-ends mode.\n>\n> My answers to these questions are both yes, and I have a neatly\n> lined up series that begins with a small bugfix and then\n> enhancement, but I do not think these do not deserve to in the\n> upcoming release. The topic came too late, and even the fix is\n> for a bug that has been with us for a long time.\n\nYeah, I think that could be useful and consistent. I took a look at\nthe grep situation in the log command briefly when writing the\noriginal patch but ended up leaving it as-is as for the time being due\nto time constraints and the like. But yeah, that behaviour is\ndefinitely desirable. I think any commands that work with grep should\nprobably follow suit, for that matter. (Are there others other than\nlog and grep itself...?)\n"},{"id":"200629","messageId":"20121005153341.GA24957@sigill.intra.peff.net","threadId":"31705","inReplyTo":"7vk3v5v9ip.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 5/6] log: pass rev_info to git_log_config()","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-10-05T15:33:41Z","receivedAt":"2012-10-05T15:33:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 04, 2012 at 09:16:14PM -0700, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > So we would need to do something like:\n> >\n> > - call git_log_config() first to let diff_context_default\n> > updated from the configuration as before. find the values of\n> > grep.* defaults at the same time, but stash it away in a\n> > separate \"struct grep_opt\" (yuck);\n> >\n> > - call init_revisions() and let it initialize revs->grep_filter\n> > and revs->diffopt as before;\n> >\n> > - copy the grep.* defaults we learned during git_log_config() to\n> > revs->grep_filter.\n> >\n> > which is a bit yucky, but survivable.\n> \n> After thinking about it a bit more, I came to a conclusion that the\n> configuration handling lifted from builtin/grep.c needs a much\n> larger overhaul.\n> [...]\n> The right way to arrange your configuration callback is probably to\n> model it after how diff configuration variables are handled. You\n> call git_config() once, and remember the values you read in set of\n> static variables. Later, whenever you need to instantiate a grep_opt,\n> you initialize it from these static variables.\n\nAgreed. Maybe the simplest thing would be to have grep_config fill in a\n\"static struct grep_opt grep_defaults\", and then memcpy that into place\nduring init_revisions?\n\n-Peff\n"},{"id":"200634","messageId":"7vtxu8u48g.fsf@alter.siamese.dyndns.org","threadId":"31705","inReplyTo":"20121005153341.GA24957@sigill.intra.peff.net","subject":"Re: [PATCH 5/6] log: pass rev_info to git_log_config()","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-05T19:07:59Z","receivedAt":"2012-10-05T19:07:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Agreed. Maybe the simplest thing would be to have grep_config fill in a\n> \"static struct grep_opt grep_defaults\", and then memcpy that into place\n> during init_revisions?\n\nYes, I was doing that for a bit last night, but then realized that\nthe grep_config() should be split into two (grep specific part and\nthen the bits that cascade to others, which is \"git grep\" specific\nrequirement; it is far better to let other callers to arrange the\ncascading themselves) before moving the grep specific bit to the\ntop-level, so that needs to come first.\n"}]}