{"thread":{"id":"35182","subject":"git grep: search whole tree by default?","startedAt":"2013-10-23T08:25:55Z","lastAt":"2013-10-25T04:52:18Z","messageCount":14,"participants":["Piotr Krukowiecki","Matthieu Moy","Junio C Hamano","Jed Brown","David Aguilar","Jeff King","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"229317","messageId":"CAA01CsqgNKdDAc9OL9zdk=3tnK9GAG=6w+wP_XSoiefBOgfzRQ@mail.gmail.com","threadId":"35182","inReplyTo":null,"subject":"git grep: search whole tree by default?","fromName":"Piotr Krukowiecki","fromEmail":"piotr.krukowiecki@gmail.com","sentAt":"2013-10-23T08:25:55Z","receivedAt":"2013-10-23T08:25:55Z","isPatch":false,"sender":{"key":"piotr.krukowiecki@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3259959?v=4"},"body":"Hi,\n\nit would be nice if grep searched not only in current directory and\nsubdirectories, but in whole tree.\n\nI know I can use \":/\" as a pathspec, but since most git commands work\ntree, I got used to this and forgot that grep is different.\n\nIt's easy to make a mistake and believe that your code does not\ncontain searched string XXX - because you have searched from a\nsubdirectory, not from the top level of your working tree. OTOH, if\ngrep searches whole tree, you'll notice you get results from outside\nof CWD and if you don't want that, you will be able to limit the\nsearch to '.'\n\nI think there were discussion about how there are several git commands\nwhich do not search in whole tree by default and that it's going to be\nchanged. I think \"add\" is one of such commands. Is 'grep' left\nunchanged?\n\nLast discussion I found is from 2011 March\n(http://thread.gmane.org/gmane.comp.version-control.git/168063/focus=168188)\nand it says it's not going to be changed :(\n\n-- \nPiotr Krukowiecki\n"},{"id":"229348","messageId":"vpqbo2guff7.fsf@anie.imag.fr","threadId":"35182","inReplyTo":"CAA01CsqgNKdDAc9OL9zdk=3tnK9GAG=6w+wP_XSoiefBOgfzRQ@mail.gmail.com","subject":"Re: git grep: search whole tree by default?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-10-23T16:21:00Z","receivedAt":"2013-10-23T16:21:00Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Piotr Krukowiecki writes:\n\n> I think there were discussion about how there are several git commands\n> which do not search in whole tree by default and that it's going to be\n> changed. I think \"add\" is one of such commands. Is 'grep' left\n> unchanged?\n\nIn summary: changing is painful. The case of \"git add\" was really bad,\nsince the same command had different behavior depending on the options\ngiven, so it was clearly worth the pain. In the case of \"git grep\", the\ncurrent behavior is not _that_ bad, so nobody bothered to do the change.\n\n(by \"do the change\", I mean propose a migration plan, convince people\nthat it is good, ...)\n\nI'd personally be slightly in favor of changing to tree-wide, but\nwithout strong opinion.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"229350","messageId":"xmqqmwlzrjdh.fsf@gitster.dls.corp.google.com","threadId":"35182","inReplyTo":"vpqbo2guff7.fsf@anie.imag.fr","subject":"Re: git grep: search whole tree by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-23T17:23:54Z","receivedAt":"2013-10-23T17:23:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> In summary: changing is painful. The case of \"git add\" was really bad,\n> since the same command had different behavior depending on the options\n> given, so it was clearly worth the pain. In the case of \"git grep\", the\n> current behavior is not _that_ bad, so nobody bothered to do the change.\n>\n> (by \"do the change\", I mean propose a migration plan, convince people\n> that it is good, ...)\n>\n> I'd personally be slightly in favor of changing to tree-wide, but\n> without strong opinion.\n\nAfter reading that old thread again, I tend to think that the only\nreason to favor \"git grep\" to start at the $(cwd) is the backward\ncompatibility. While I do expect that many people will be annoyed\nwhen \"git grep\" (no pathspecs) that is run in a subdirectory starts\nspitting out a large number of hits from places irrelevant for the\ncurrent task at hand, hits from outside the $(cwd) is something they\ncan _notice_ easily and their fingers will quickly learn to add \".\"\nwithout even thinking.\n\nI suspect that it would be too late for 2.0 we want to do sometime\nearly next year, though.\n"},{"id":"229357","messageId":"87hac7hmrb.fsf@mcs.anl.gov","threadId":"35182","inReplyTo":"xmqqmwlzrjdh.fsf@gitster.dls.corp.google.com","subject":"Re: git grep: search whole tree by default?","fromName":"Jed Brown","fromEmail":"jed@59a2.org","sentAt":"2013-10-23T18:20:56Z","receivedAt":"2013-10-23T18:20:56Z","isPatch":false,"sender":{"key":"jed@59a2.org","avatar":"https://gravatar.com/avatar/1391d04d82555f9058a9fdf5eead233e909a48e40480db31fc554e7afeb301da?d=mp&s=160"},"body":"Junio C Hamano writes:\n> I suspect that it would be too late for 2.0 we want to do sometime\n> early next year, though.\n\nHow would you manage transition from the current behavior? Warning\npeople to explicitly use \".\" or \":/\" during some interim period sounds\nworse than just switching the default behavior.\n"},{"id":"229362","messageId":"xmqqob6fq0q1.fsf@gitster.dls.corp.google.com","threadId":"35182","inReplyTo":"87hac7hmrb.fsf@mcs.anl.gov","subject":"Re: git grep: search whole tree by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-23T18:52:06Z","receivedAt":"2013-10-23T18:52:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jed Brown writes:\n\n> Junio C Hamano writes:\n>> I suspect that it would be too late for 2.0 we want to do sometime\n>> early next year, though.\n>\n> How would you manage transition from the current behavior? Warning\n> people to explicitly use \".\" or \":/\" during some interim period sounds\n> worse than just switching the default behavior.\n\n\"How would I\"?\n\nYou're asking that question only because you omitted too much from\nthe quote ;-)\n\nMatthieu Moy wrote:\n\n> In summary: changing is painful. The case of \"git add\" was really bad,\n> since the same command had different behavior depending on the options\n> given, so it was clearly worth the pain. In the case of \"git grep\", the\n> current behavior is not _that_ bad, so nobody bothered to do the change.\n>\n> (by \"do the change\", I mean propose a migration plan, convince people\n> that it is good, ...)\n\nI agree that it is up to those who really want to switch the\ndefault.\n"},{"id":"229363","messageId":"87zjpzg592.fsf@mcs.anl.gov","threadId":"35182","inReplyTo":"xmqqob6fq0q1.fsf@gitster.dls.corp.google.com","subject":"Re: git grep: search whole tree by default?","fromName":"Jed Brown","fromEmail":"jed@59a2.org","sentAt":"2013-10-23T19:24:25Z","receivedAt":"2013-10-23T19:24:25Z","isPatch":false,"sender":{"key":"jed@59a2.org","avatar":"https://gravatar.com/avatar/1391d04d82555f9058a9fdf5eead233e909a48e40480db31fc554e7afeb301da?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Jed Brown writes:\n>\n>> Junio C Hamano writes:\n>>> I suspect that it would be too late for 2.0 we want to do sometime\n>>> early next year, though.\n>>\n>> How would you manage transition from the current behavior? Warning\n>> people to explicitly use \".\" or \":/\" during some interim period sounds\n>> worse than just switching the default behavior.\n>\n> \"How would I\"?\n>\n> You're asking that question only because you omitted too much from\n> the quote ;-)\n\nI meant that if the proposed migration plan were to be \"just change it\nand people will learn\" (because anything more gradual would actually be\nworse for users) then is it really too late for Git-2.0?\n"},{"id":"229365","messageId":"xmqqk3h3pywt.fsf@gitster.dls.corp.google.com","threadId":"35182","inReplyTo":"87zjpzg592.fsf@mcs.anl.gov","subject":"Re: git grep: search whole tree by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-23T19:31:14Z","receivedAt":"2013-10-23T19:31:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jed Brown writes:\n\n> Junio C Hamano writes:\n>\n>> Jed Brown writes:\n>>\n>>> Junio C Hamano writes:\n>>>> I suspect that it would be too late for 2.0 we want to do sometime\n>>>> early next year, though.\n>>>\n>>> How would you manage transition from the current behavior? Warning\n>>> people to explicitly use \".\" or \":/\" during some interim period sounds\n>>> worse than just switching the default behavior.\n>>\n>> \"How would I\"?\n>>\n>> You're asking that question only because you omitted too much from\n>> the quote ;-)\n>\n> I meant that if the proposed migration plan were to be \"just change it\n> and people will learn\" (because anything more gradual would actually be\n> worse for users) then is it really too late for Git-2.0?\n\nI do not know it that is even a workable plan, but I need to sleep\non it and then hear opinion from others, but in general, if anybody\nneeds to ask if it is too late, then it already is.\n"},{"id":"229367","messageId":"vpqy55jogzr.fsf@anie.imag.fr","threadId":"35182","inReplyTo":"87zjpzg592.fsf@mcs.anl.gov","subject":"Re: git grep: search whole tree by default?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-10-23T20:43:36Z","receivedAt":"2013-10-23T20:43:36Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jed Brown writes:\n\n> Junio C Hamano writes:\n>\n>> Jed Brown writes:\n>>\n>>> Junio C Hamano writes:\n>>>> I suspect that it would be too late for 2.0 we want to do sometime\n>>>> early next year, though.\n>>>\n>>> How would you manage transition from the current behavior? Warning\n>>> people to explicitly use \".\" or \":/\" during some interim period sounds\n>>> worse than just switching the default behavior.\n>>\n>> \"How would I\"?\n>>\n>> You're asking that question only because you omitted too much from\n>> the quote ;-)\n>\n> I meant that if the proposed migration plan were to be \"just change it\n> and people will learn\" (because anything more gradual would actually be\n> worse for users) then is it really too late for Git-2.0?\n\nThat may be an option. In the case of \"git add -u\", it was a bit more\ncomplicated, since a badly used \"git add\" somehow looses data (not very\nserious, you may only loos the index). So, saying after the fact \"oh, by\nthe way, I messed up the index\" was not a very good transition plan.\n\nIn the case of \"grep\", I'm starting to get convinced that it's OK to do\nso, because the user can basically re-run grep with the right argument\nif needed.\n\nThe warning could be de-activable with an advice.* option.\n\nAgain, no strong opinion here, but that seems workable to me.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"229376","messageId":"CAJDDKr7BkZjhjPF==v6PWVA4_-HM2cOaj+xusgkLKf7OocEpaw@mail.gmail.com","threadId":"35182","inReplyTo":"xmqqk3h3pywt.fsf@gitster.dls.corp.google.com","subject":"Re: git grep: search whole tree by default?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-10-24T02:15:25Z","receivedAt":"2013-10-24T02:15:25Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Wed, Oct 23, 2013 at 12:31 PM, Junio C Hamano wrote:\n> Jed Brown writes:\n>\n>> Junio C Hamano writes:\n>>\n>>> Jed Brown writes:\n>>>\n>>>> Junio C Hamano writes:\n>>>>> I suspect that it would be too late for 2.0 we want to do sometime\n>>>>> early next year, though.\n>>>>\n>>>> How would you manage transition from the current behavior? Warning\n>>>> people to explicitly use \".\" or \":/\" during some interim period sounds\n>>>> worse than just switching the default behavior.\n>>>\n>>> \"How would I\"?\n>>>\n>>> You're asking that question only because you omitted too much from\n>>> the quote ;-)\n>>\n>> I meant that if the proposed migration plan were to be \"just change it\n>> and people will learn\" (because anything more gradual would actually be\n>> worse for users) then is it really too late for Git-2.0?\n>\n> I do not know it that is even a workable plan, but I need to sleep\n> on it and then hear opinion from others, but in general, if anybody\n> needs to ask if it is too late, then it already is.\n\nMaking grep tree-wide would be very welcome here.\n\nIMO Git-2.0 *feels* like a good time to change the default since\nthere's relatively little downside to doing so, but \"early next year\"\nis not very long to wait either; it doesn't seem like there's a strong\nreason to rush this in.\n-- \nDavid\n"},{"id":"229377","messageId":"20131024022736.GA24992@sigill.intra.peff.net","threadId":"35182","inReplyTo":"vpqy55jogzr.fsf@anie.imag.fr","subject":"Re: git grep: search whole tree by default?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-10-24T02:27:36Z","receivedAt":"2013-10-24T02:27:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 23, 2013 at 10:43:36PM +0200, Matthieu Moy wrote:\n\n> That may be an option. In the case of \"git add -u\", it was a bit more\n> complicated, since a badly used \"git add\" somehow looses data (not very\n> serious, you may only loos the index). So, saying after the fact \"oh, by\n> the way, I messed up the index\" was not a very good transition plan.\n> \n> In the case of \"grep\", I'm starting to get convinced that it's OK to do\n> so, because the user can basically re-run grep with the right argument\n> if needed.\n\nFor the same reason, is it insane to want a config option to switch the\ndefault when no command-line option is given? These days I am mostly\nworking on reasonably-sized projects, and would generally prefer\nfull-tree grep. But in a past life, I worked on some large projects\nwhere I would never touch anything outside of a particular subtree, and\nI generally wanted a more limited grep (i.e., I would park my cwd in\n/repo/subsystem1 rather than /repo and work from there, and hits in\n/repo/subsystem2 were just useless noise).\n\nThat would also provide people who do not like the change of default an\nescape hatch to keep the current behavior. And I do not think scripted\nuse will be inconvenienced; they will already have to use \".\" or \":/\" to\nbe explicit (if they care) since the behavior is changing.\n\n> The warning could be de-activable with an advice.* option.\n\nSuch a config option could also be used to shut up the warning. Though\nif the behavior change is deemed non-intrusive enough to not merit a\ndeprecation period, I am not really sure it is worth having a noisy\nwarning.\n\n-Peff\n"},{"id":"229426","messageId":"xmqqd2muo3sz.fsf@gitster.dls.corp.google.com","threadId":"35182","inReplyTo":"20131024022736.GA24992@sigill.intra.peff.net","subject":"Re: git grep: search whole tree by default?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-10-24T19:40:44Z","receivedAt":"2013-10-24T19:40:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> That would also provide people who do not like the change of default an\n> escape hatch to keep the current behavior. And I do not think scripted\n> use will be inconvenienced; they will already have to use \".\" or \":/\" to\n> be explicit (if they care) since the behavior is changing.\n\nThere is a big difference between \"scripted use will have an escape\nhatch\" and \"scripted use will not be inconvenienced\". We *know*\nscripts will be inconvenienced with or without such a configuration\nvariable, as they *have* to be updated if they rely on the current\nbehaviour of \"git grep\" that limits its search to the current\ndirectory when fed no pathspec (and if their users want to keep the\ncurrent behaviour of such scripts). Anything short of a warning (or\neven erroring out) that is designed to annoy the users during the\ntransition period will help ease the pain of transition of scripts.\n\nAn annoying warning still can only *ease*, but cannot eliminate, the\npain of transition. The scripts need to be updated to adjust to the\nnew behaviour; there is no getting around to it.\n\nEven if we ignore the \"helping your colleague at her terminal\", cf.\n\n http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133683\n\nissue for now, adding a new configuration variable from day one\nmakes the transition of scripts somewhat worse, I am afraid. Doing\nso robs us a way to add such an annoying warning to help people\nforesee problems in their existing scripts before the default\nchanges (the configuration presumably will disable the \"this command\nline will behave differently after the default changes\" warning).\n\nAs I said, I think we can train people without an annoying warning,\nas hits outside their current directory will serve as an annoyance\nalready, and people who set such a configuration in their repository\n(or $HOME/.gitconfig), get used to the chosen behaviour too much,\nand get surprised when they get to use a vanilla intallation of Git\n(either helping colleague or setting up a new work environment) have\nonly themselves to blame, so it may not be too big a deal.\n\nBut I do not think the same reasoning extends to scripted uses X-<.\n"},{"id":"229456","messageId":"CAJDDKr5G_dpk5s6EMBF=iU+yHkr7TKYRUBJAxBQY9Y9jy6FmCA@mail.gmail.com","threadId":"35182","inReplyTo":"xmqqd2muo3sz.fsf@gitster.dls.corp.google.com","subject":"Re: git grep: search whole tree by default?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-10-25T02:23:49Z","receivedAt":"2013-10-25T02:23:49Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Oct 24, 2013 at 12:40 PM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>> That would also provide people who do not like the change of default an\n>> escape hatch to keep the current behavior. And I do not think scripted\n>> use will be inconvenienced; they will already have to use \".\" or \":/\" to\n>> be explicit (if they care) since the behavior is changing.\n>\n> There is a big difference between \"scripted use will have an escape\n> hatch\" and \"scripted use will not be inconvenienced\". We *know*\n> scripts will be inconvenienced with or without such a configuration\n> variable, as they *have* to be updated if they rely on the current\n> behaviour of \"git grep\" that limits its search to the current\n> directory when fed no pathspec (and if their users want to keep the\n> current behaviour of such scripts). Anything short of a warning (or\n> even erroring out) that is designed to annoy the users during the\n> transition period will help ease the pain of transition of scripts.\n>\n> An annoying warning still can only *ease*, but cannot eliminate, the\n> pain of transition. The scripts need to be updated to adjust to the\n> new behaviour; there is no getting around to it.\n>\n> Even if we ignore the \"helping your colleague at her terminal\", cf.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133683\n>\n> issue for now, adding a new configuration variable from day one\n> makes the transition of scripts somewhat worse, I am afraid. Doing\n> so robs us a way to add such an annoying warning to help people\n> foresee problems in their existing scripts before the default\n> changes (the configuration presumably will disable the \"this command\n> line will behave differently after the default changes\" warning).\n>\n> As I said, I think we can train people without an annoying warning,\n> as hits outside their current directory will serve as an annoyance\n> already, and people who set such a configuration in their repository\n> (or $HOME/.gitconfig), get used to the chosen behaviour too much,\n> and get surprised when they get to use a vanilla intallation of Git\n> (either helping colleague or setting up a new work environment) have\n> only themselves to blame, so it may not be too big a deal.\n>\n> But I do not think the same reasoning extends to scripted uses X-<.\n\nThe set of people that script \"git grep\" may in fact be pretty low /\nalmost non-existent so it may be a non-issue, but here's my one data\npoint:\n\nFor git-cola, this change in behavior would not make any difference.\nIt already jumps to the top-level during startup so its grep feature\nis unaffected.\n\nIt'd be good to hear from other script writers but that's my $.02.\n-- \nDavid\n"},{"id":"229471","messageId":"20131025043717.GC11810@sigill.intra.peff.net","threadId":"35182","inReplyTo":"xmqqd2muo3sz.fsf@gitster.dls.corp.google.com","subject":"Re: git grep: search whole tree by default?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-10-25T04:37:17Z","receivedAt":"2013-10-25T04:37:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > That would also provide people who do not like the change of default an\n> > escape hatch to keep the current behavior. And I do not think scripted\n> > use will be inconvenienced; they will already have to use \".\" or \":/\" to\n> > be explicit (if they care) since the behavior is changing.\n> \n> There is a big difference between \"scripted use will have an escape\n> hatch\" and \"scripted use will not be inconvenienced\".\n\nI think my communication may have been muddled in transit. What I meant\nregarding inconvenienced was \"not any more so than by simply changing\nthe behavior in the first place, since scripts already will need to\nstart becoming explicit due to the behavior change\".\n\nAnd for the \"escape hatch\", I did not mean for scripts. I actually meant\nfor users who do not like the extra typing and complain \"stupid git, I\nalways want '.'; you used to do what I want and now you do not\".\n\n> Even if we ignore the \"helping your colleague at her terminal\", cf.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/133570/focus=133683\n\nFWIW, I have never agreed with that line of reasoning. I was going to\nexplain why, but I see that I already did in response to the article you\nlinked. :)\n\n> issue for now, adding a new configuration variable from day one\n> makes the transition of scripts somewhat worse, I am afraid. Doing\n> so robs us a way to add such an annoying warning to help people\n> foresee problems in their existing scripts before the default\n> changes (the configuration presumably will disable the \"this command\n> line will behave differently after the default changes\" warning).\n\nIf you want to have an annoying warning, why not consider the config a\ntristate? Do X or do Y, or if unset, do X with an annoying warning\n(which will switch to Y in the future). That does not help a user who\nsets the variable after seeing the warning the first time, then later\nruns a script that silently chooses the wrong behavior.\n\nBut neither does a warning that is squelched by advice.*, which the user\nwill also set soon after seeing it.\n\nThe only way to hit those scripts is to yell at the user anytime the\nappropriate command-line override is not selected, with no way to turn\nit off. That's what we're doing now with \"git add\". I think people find\nit a little annoying. But perhaps it is the least of all evils.\n\n\nAnyway, I have said my piece, and I think we are on the same page with\nthe tradeoffs (what they are, though we may value them differently). I\ndo not care that strongly about the config option these days; as I said,\nit was something I would have used in certain workflows, but I do not\nforesee myself even setting it these days. So I am willing to forego it\nif there are concerns it will make things worse.\n\n-Peff\n"},{"id":"229473","messageId":"CACsJy8Cm7eShj22hve7=u2K5DKhv-t_KNUreRC+FZoehgfyEkg@mail.gmail.com","threadId":"35182","inReplyTo":"20131025043717.GC11810@sigill.intra.peff.net","subject":"Re: git grep: search whole tree by default?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-10-25T04:52:18Z","receivedAt":"2013-10-25T04:52:18Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Oct 25, 2013 at 11:37 AM, Jeff King wrote:\n> On Thu, Oct 24, 2013 at 12:40:44PM -0700, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>>\n>> > That would also provide people who do not like the change of default an\n>> > escape hatch to keep the current behavior. And I do not think scripted\n>> > use will be inconvenienced; they will already have to use \".\" or \":/\" to\n>> > be explicit (if they care) since the behavior is changing.\n>>\n>> There is a big difference between \"scripted use will have an escape\n>> hatch\" and \"scripted use will not be inconvenienced\".\n>\n> I think my communication may have been muddled in transit. What I meant\n> regarding inconvenienced was \"not any more so than by simply changing\n> the behavior in the first place, since scripts already will need to\n> start becoming explicit due to the behavior change\".\n>\n> And for the \"escape hatch\", I did not mean for scripts. I actually meant\n> for users who do not like the extra typing and complain \"stupid git, I\n> always want '.'; you used to do what I want and now you do not\".\n\nSuch an escape hatch may be better done as an alias than a config key\n(an alias is a config key anyway). I know it won't be easy to \"add '.'\nif no pathspecs are given\", using shell script. But that's something\nwe could improve, hopefully. An option is we could just export\nPATHSPEC_PREFER_* flags via a command line (like --literal-pathspecs).\n-- \nDuy\n"}]}