{"thread":{"id":"21734","subject":"[PATCH] grep: --full-tree","startedAt":"2009-11-24T08:56:32Z","lastAt":"2009-11-29T19:50:50Z","messageCount":68,"participants":["Junio C Hamano","Michael J Gruber","Sverre Rabbelier","Jeff King","James Pickens","A Large Angry SCM","Wincent Colaiuta","Johannes Schindelin","Matthieu Moy","Uri Okrent","Felipe Contreras"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"128239","messageId":"7vk4xggv27.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":null,"subject":"[PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-24T08:56:32Z","receivedAt":"2009-11-24T08:56:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"While working inside a deep subdirectory, it sometimes is necessary to\nfind a string you see in a file you are working on from the files in the\nentire project. This is especially true when you are dipping your toe\ninto an unfamiliar project.\n\nBy default, \"git grep\" limits its search space to the current directory\nand below (i.e. as if \"-r .\" is specified), and it is rather cumbersome to\nrepeat ../ as many times as necessary. This new option tells \"git grep\"\nnot to limit the search space to the current directory.\n\nSigned-off-by: Junio C Hamano \n---\n\n * In http://article.gmane.org/gmane.comp.version-control.git/111717, I\n once argued in the opposite way, but I think it is Ok to aim for making\n the default --full-tree in the longer run (cf. $gmane/127885). This is\n the first step in that direction.\n\n I am not sure if there can be a sane way to flip the default without\n hurting existing scripts and users. Backward compatibility always is\n a pain.\n\n builtin-grep.c | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex 761799d..5787f35 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -693,6 +693,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n {\n \tint hit = 0;\n \tint cached = 0;\n+\tint full_tree = 0;\n \tint external_grep_allowed = 1;\n \tint seen_dashdash = 0;\n \tstruct grep_opt opt;\n@@ -732,6 +733,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\tOPT_BIT('H', NULL, &opt.pathname, \"show filenames\", 1),\n \t\tOPT_NEGBIT(0, \"full-name\", &opt.relative,\n \t\t\t\"show filenames relative to top directory\", 1),\n+\t\tOPT_BIT(0, \"full-tree\", &full_tree,\n+\t\t\t\"search from the top of the tree\", 1),\n \t\tOPT_BOOLEAN('l', \"files-with-matches\", &opt.name_only,\n \t\t\t\"show only filenames instead of matching lines\"),\n \t\tOPT_BOOLEAN(0, \"name-only\", &opt.name_only,\n@@ -862,7 +865,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \n \tif (i < argc)\n \t\tpaths = get_pathspec(prefix, argv + i);\n-\telse if (prefix) {\n+\telse if (prefix && !full_tree) {\n \t\tpaths = xcalloc(2, sizeof(const char *));\n \t\tpaths[0] = prefix;\n \t\tpaths[1] = NULL;\n-- \n1.6.6.rc0.47.g1fdffa.dirty\n"},{"id":"128307","messageId":"4B0D2E19.6020100@drmicha.warpmail.net","threadId":"21734","inReplyTo":"7vk4xggv27.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-25T13:16:09Z","receivedAt":"2009-11-25T13:16:09Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 24.11.2009 09:56:\n> While working inside a deep subdirectory, it sometimes is necessary to\n> find a string you see in a file you are working on from the files in the\n> entire project. This is especially true when you are dipping your toe\n> into an unfamiliar project.\n> \n> By default, \"git grep\" limits its search space to the current directory\n> and below (i.e. as if \"-r .\" is specified), and it is rather cumbersome to\n> repeat ../ as many times as necessary. This new option tells \"git grep\"\n> not to limit the search space to the current directory.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> \n> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I\n> once argued in the opposite way, but I think it is Ok to aim for making\n> the default --full-tree in the longer run (cf. $gmane/127885). This is\n> the first step in that direction.\n> \n> I am not sure if there can be a sane way to flip the default without\n> hurting existing scripts and users. Backward compatibility always is\n> a pain.\n\nOn a related note, I had planned for a while now to go through the\ncommands and check for inconsistencies w.r.t. to subdir default. For\nexample, ls-files behaves like grep, whereas status is different. We\nalready had discussions about the commit:path notation from a subdir. (I\ndon't remember the outcome.) Of course, defaulting status differently\ncould be dangerous. Having --full-tree as default for all commands and\nrequiring an explicit \".\" sounds safer for all commands and not overly\ninconvenient. (I remember once wondering where my committed files are,\nlooking at git ls-files output from a subdir.)\n\nI think we should make this behavior as uniform across commands as\npossible. Do we have a time frame for 1.7.0 within which one should\nachieve such incompatible changes?\n\nMichael\n"},{"id":"128315","messageId":"fabb9a1e0911250656k31229c42jd79fb94c1a619e59@mail.gmail.com","threadId":"21734","inReplyTo":"7vk4xggv27.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-25T14:56:49Z","receivedAt":"2009-11-25T14:56:49Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Tue, Nov 24, 2009 at 09:56, Junio C Hamano wrote:\n>   I am not sure if there can be a sane way to flip the default without\n>   hurting existing scripts and users.  Backward compatibility always is\n>   a pain.\n\nI regularly rely on this behavior in my usage of git grep. For\nexample, the Melange project has this layout:\n-- app\n-- app/soc\n-- app/django\n-- app/... etc\n-- scripts\n-- tests\n-- thirdparty\n\nI almost always want only results from \"app/soc\", so when I run git\ngrep I do so from within \"app/soc\" to make sure I don't get false\npositives from the many external sources we have.\n\nJust chiming in for the \"want to keep the current behavior\" camp :).\n\nPS: I don't mind having to set a config variable to keep the current\nbehavior though.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128329","messageId":"7vws1ewgbr.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"4B0D2E19.6020100@drmicha.warpmail.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T19:32:40Z","receivedAt":"2009-11-25T19:32:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 24.11.2009 09:56:\n>> While working inside a deep subdirectory, it sometimes is necessary to\n>> find a string you see in a file you are working on from the files in the\n>> entire project. This is especially true when you are dipping your toe\n>> into an unfamiliar project.\n>> \n>> By default, \"git grep\" limits its search space to the current directory\n>> and below (i.e. as if \"-r .\" is specified), and it is rather cumbersome to\n>> repeat ../ as many times as necessary. This new option tells \"git grep\"\n>> not to limit the search space to the current directory.\n>> \n>> Signed-off-by: Junio C Hamano \n>> ---\n>> \n>> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I\n>> once argued in the opposite way, but I think it is Ok to aim for making\n>> the default --full-tree in the longer run (cf. $gmane/127885). This is\n>> the first step in that direction.\n>> \n>> I am not sure if there can be a sane way to flip the default without\n>> hurting existing scripts and users. Backward compatibility always is\n>> a pain.\n>\n> On a related note, I had planned for a while now to go through the\n> commands and check for inconsistencies w.r.t. to subdir default. For\n> example, ls-files behaves like grep, whereas status is different. We\n> already had discussions about the commit:path notation from a subdir. (I\n> don't remember the outcome.) Of course, defaulting status differently\n> could be dangerous. Having --full-tree as default for all commands and\n> requiring an explicit \".\" sounds safer for all commands and not overly\n> inconvenient. (I remember once wondering where my committed files are,\n> looking at git ls-files output from a subdir.)\n>\n> I think we should make this behavior as uniform across commands as\n> possible. Do we have a time frame for 1.7.0 within which one should\n> achieve such incompatible changes?\n\nI do not think there is such a consensus for a blanket change like that.\n\nIf you are starting a discussion to build one for a particular change (not\nnecessarily the one you mentioned above) now, you are way too late for\n1.7.0. The changes scheduled for 1.7.0 were glitches we have known for\nquite some time, and more importantly had a concensus on _how_ they should\nbe handled long before 1.6.3 (May 6, 2009), and the most importantly, the\nsteps in the transition plan since then have already been executing.\n\n - The plan for \"git push\" changes were already announced in 1.6.3, and\n the first step of transition was implemented there.\n\n - We already had consensus for changing the default \"send-email\"\n threading behaviour before 1.6.2 and it was scheduled to happen in\n 1.6.3 but has been deferred until now.\n\n - For a long time, it has been known that it is confusing and unexpected\n to users that \"git status\" is a synonym for \"git commit --dry-run\".\n The plan to make \"git status\" different from \"git commit --dry-run\" has\n been done in mid August this year.\n\n - For a long time, \"git diff\" considered -b/-w options are only for\n controlling generation of patch text, and these options didn't affect\n the exit status (when run with --exit-code) nor suppress the patch\n header lines (i.e. \"diff --git\"). This could be argued as a bug (the\n same way as \"some commands are relative to cwd by default and others\n are relative to the whole tree\" can be), but it doesn't mean we can\n blame user's scripts for relying on the bug and change the semantics\n all of sudden. We had been cooking the change since May 2009 and\n announcements were in all issues of \"What's cooking\" since Aug 2009 for\n this change.\n\nAlso, please do not confuse 1.7.0 with a license for \"I do not like this\nand that, screw backward compatibility, and change things as if we were\nbuilding git from scratch without any existing users\". We need a solid\ntransition plan to ease the pain for existing scripts and users.\n\nAs to ls-files, I haven't seen any good proposal of a smooth transition\nplan (like what we laid out for a few semantic changes for \"git push\" for\n1.7.0), if we were to eventually change it, and I personally do not think\nthere can be a smooth transition for that particular command. It is used\nas a very low level building block for people's scripts, and I don't think\nof a way to change its fundamental behaviour without causing people a lot\nof extra work. I doubt you can easily build a concensus that the benefit\nof \"consistency\" is worth it for such a change.\n\n Side note. What we _could_ do is to make ls-files less (much less)\n necessary at the UI level for you to _type_ from the command line.\n Enumerate in what situations you used the command, think about the\n reason for each of occasions why you used it (e.g. \"after a conflicted\n merge I wanted to find out which paths are still unresolved and\n 'ls-files -u' was the most convenient way\"), and eliminate the reason\n (e.g. \"add a new (option to 'merge'|command) that reports the needed\n information in much more readable way than 'ls-files -u' does).\n\nThe same applies to \"$treeish:$path\" syntax.\n\nIt may be convenient if there were to specify \"I want to name the path in\nHEAD~47 that corresponds to this file in the directory I am currently in.\"\nBut that does not necessarily mean we should change the semantics and\nbreak existing users. One way to satisfy the wish without breaking\nexisting users would be to start accepting \"$treeish:./$relative\".\n"},{"id":"128330","messageId":"7vr5rmwgbn.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"fabb9a1e0911250656k31229c42jd79fb94c1a619e59@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T19:32:44Z","receivedAt":"2009-11-25T19:32:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> I almost always want only results from \"app/soc\", so when I run git\n> grep I do so from within \"app/soc\" to make sure I don't get false\n> positives from the many external sources we have.\n\nThe standard answer given by others has been \"you can always say '.' at\nthe end; having to remember/count number of ../ necessary is much much\nmore inconvenient\".\n\n> PS: I don't mind having to set a config variable to keep the current\n> behavior though.\n\nI've thought about it for five seconds before sending my patch, but\ndiscarded it, because I do not see it as a good transition plan.\n\nIf it were something like \"git-push\", that is a purely Porcelain for\ncausing _effect_ to outside world, the customizable behaviour of the\ncommand depending on which repository it is run is excusable and may even\nbe beneficial.\n\nBut if a command like \"grep\" that \"does one small thing and do it well\"\nchanges its behaviour drastically depending on a config variable or an\nenvironment variable, it won't be a command that you can rely upon any\nmore in your scripts and hooks. It's the same insanity as GREP_OPTIONS\nenvironment variable.\n\nSo this change, if we were to do it, unfortunately has to be \"we do it\nonce and for everybody\" a flag day event, I think. That is what I am not\nenthused about this patch.\n"},{"id":"128334","messageId":"fabb9a1e0911251219t3ad0dacen67d8615ef6eefa02@mail.gmail.com","threadId":"21734","inReplyTo":"7vr5rmwgbn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-25T20:19:36Z","receivedAt":"2009-11-25T20:19:36Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Nov 25, 2009 at 20:32, Junio C Hamano wrote:\n> The standard answer given by others has been \"you can always say '.' at\n> the end; having to remember/count number of ../ necessary is much much\n> more inconvenient\".\n\nA commandline flag to keep the old behavior then perhaps? \"git config\nalias.gr 'grep --no-full-tree'\" is not that hard to write either.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128336","messageId":"7vd436uzet.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"fabb9a1e0911251219t3ad0dacen67d8615ef6eefa02@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T20:23:22Z","receivedAt":"2009-11-25T20:23:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Wed, Nov 25, 2009 at 20:32, Junio C Hamano wrote:\n>> The standard answer given by others has been \"you can always say '.' at\n>> the end; having to remember/count number of ../ necessary is much much\n>> more inconvenient\".\n>\n> A commandline flag to keep the old behavior then perhaps? \"git config\n> alias.gr 'grep --no-full-tree'\" is not that hard to write either.\n\nBut then you can alias \"gr 'grep --full-tree'\" with the same ease and\nthere is no reason to change the default.\n"},{"id":"128337","messageId":"20091125203922.GA18487@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7vk4xggv27.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T20:39:23Z","receivedAt":"2009-11-25T20:39:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote:\n\n> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I\n> once argued in the opposite way, but I think it is Ok to aim for making\n> the default --full-tree in the longer run (cf. $gmane/127885). This is\n> the first step in that direction.\n\nIronically, I argued for --full-tree behavior in the same thread, but\nhave since softened my view. What I have come to realize is that (for\nme, anyway) it is very dependent on the organization of the project you\nare working on.\n\nFor git.git, and most of my small-ish other projects, I want \"git grep\"\nto search the full tree. But recently, I have been working on a\nlarge-ish project imported from svn where the parts of interest to me\nare rooted two directories deep (i.e., I am working in\n\"linux/subproject/\", and I don't care at all what's happening in\n\"windows/otherproject\"). I don't want grep hits from the other area to\nclutter my output, and I especially don't want to waste time hitting the\ndisk for those pages, which are an order of magnitude larger than the\nworking set of files that are actually of interest to me.\n\nOn top of that, I think there are two ways within a logical subproject\nto use subdirectories. In git.git, I tend to actually chdir into\nDocumentation/ or t/, because they have their own Makefiles. But for a\nproject that organizes its code into a bunch of module subdirectories\nall driven by a top-level non-recursive Makefile, I tend to stay at the\nroot and actually do \"vi module/foo.c; make\".\n\nSo what that tells me is:\n\n 1. It is not necessarily the _developer_, but a combination of\n developer and project that decides which behavior (of --full-tree\n and the current behavior) is more useful. Which to me really points\n to the utility of a config option.\n\n 2. It would be useful to have a \"partial-tree\" middle ground. In other\n words, if I am in \"linux/subproject/t\", I would find it most\n useful if \"git grep\" searched all of \"linux/subproject\".\n Implementing that would become much more complex, though. Probably\n the user would specify a list of rooted subprojects, and we would\n prefix-match our path to find which one we were in, and then\n do a full-tree grep on that subtree.\n\n And yes, this is somewhat an argument in favor of splitting the\n project into submodules. But I'd really rather not do that. They\n introduce significant complexity, and the rest of git is so _good_\n at ignoring uninteresting parts.\n\n-Peff\n"},{"id":"128338","messageId":"fabb9a1e0911251246l4684f357pb5f379b191aaa64a@mail.gmail.com","threadId":"21734","inReplyTo":"7vd436uzet.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-25T20:46:01Z","receivedAt":"2009-11-25T20:46:01Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Wed, Nov 25, 2009 at 21:23, Junio C Hamano wrote:\n> But then you can alias \"gr 'grep --full-tree'\" with the same ease and\n> there is no reason to change the default.\n\nI agree, but then again I'm somewhat biased, as I want the current behavior :P.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128339","messageId":"7viqcytjic.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091125203922.GA18487@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T20:52:11Z","receivedAt":"2009-11-25T20:52:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Nov 24, 2009 at 12:56:32AM -0800, Junio C Hamano wrote:\n>\n>> * In http://article.gmane.org/gmane.comp.version-control.git/111717, I\n>> once argued in the opposite way, but I think it is Ok to aim for making\n>> the default --full-tree in the longer run (cf. $gmane/127885). This is\n>> the first step in that direction.\n>\n> Ironically, I argued for --full-tree behavior in the same thread, but\n> have since softened my view. What I have come to realize is that (for\n> me, anyway) it is very dependent on the organization of the project you\n> are working on.\n\nI was against --full-tree but wished for it when I dipped my toe into\nsomebody else's project and my itch lived in a directory a few levels\ndeep, while the infrastructure the files in the directory uses were spread\nacross global include directory and platform implementations [*1*].\n\nAnd I agree that the preferred behaviour depends largely on both the\nproject and what kind of change you are currently scratching.\n\nSo I think the posted patch alone without changing anything else would be\nthe approach to give the most benefit with the least impact to existing\nusers, at least for now.\n\n> 2. It would be useful to have a \"partial-tree\" middle ground. In other\n> words, if I am in \"linux/subproject/t\", I would find it most\n> useful if \"git grep\" searched all of \"linux/subproject\".\n\n\"git grep -e frotz ..\" will work in your \"from linux/subproject/t look for\neverywhere in linux/subproject\", but if \"/t\" part were much longer and\nvariable (iow you need to chdir around inside linux/subproject to scratch\nyour itch) compared to \"linux/subproject\" part that is much shorter and\nstatic (to your work), it may make sense to give us a mode to specify\npathspec from the top of the tree.\n\n $ cd linux/subproject\n $ cd foo\n $ cd bar\n $ cd baz\n $ git grep --absolute-pathspec -e frotz -- linux/subproject\n\nAs \"git grep\" never takes absolute paths, we _might_ be able to also do\n\n $ git grep -e frotz -- /linux/subproject\n\nto achieve the same.\n\n\n[Footnote]\n\n*1* It's rockbox, if you need to know.\n"},{"id":"128340","messageId":"20091125205232.GB18487@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7vr5rmwgbn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T20:52:32Z","receivedAt":"2009-11-25T20:52:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 11:32:44AM -0800, Junio C Hamano wrote:\n\n> But if a command like \"grep\" that \"does one small thing and do it well\"\n> changes its behaviour drastically depending on a config variable or an\n> environment variable, it won't be a command that you can rely upon any\n> more in your scripts and hooks. It's the same insanity as GREP_OPTIONS\n> environment variable.\n\nI know this is the attitude we have taken in the past, and I am worried\nit is part of what hurts the usability of git. Just consider for a\nmoment: git grows some feature with a default behavior X. Time passes.\nSome people like behavior Y instead. How can we help the people who like\nY?\n\n 1. Declare Y better than X, and default to it. This hurts people who\n like X. It also hurts scripts built around X.\n\n 2. Add a config option to switch the behavior to Y. This hurts people\n or scripts unexpectedly using somebody's configuration with Y.\n\n 3. Add a --Y command line option. Now the Y people have to remember to\n use that option. Every single time they invoke the command.\n\n 4. Tell them to alias \"git foo-y\" to \"git foo --Y\". IMHO, this is\n completely unscalable. They can't just call it \"foo\", so they have\n to remember to invoke \"foo-y\" each time. And when they forget,\n instead of getting an error, they get the X behavior. Furthermore,\n as time goes on, they basically develop a vocabulary of git\n commands that is totally unlike anybody else's, making their\n scripts and git knowledge unportable to other people's setups (sort\n of like in (2) above).\n\nSo as a Y user, what is the impression of git that I am left with? It\ndoesn't do what I want unless I remember an option every time, or create\nan arcane pseudo-porcelain interface through my set of aliases. Patches\nto fix the situation are blocked by compatibility issues. Y users remain\nfrustrated indefinitely.\n\nI know that (1) and (2) have their problems. But I think by not giving a\nlittle on those compatibility issues, we end up with an equally bad or\nworse outcome. In other words, I think in this case that (2) may be the\nlesser of many evils.\n\n-Peff\n"},{"id":"128342","messageId":"20091125210034.GC18487@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7viqcytjic.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T21:00:34Z","receivedAt":"2009-11-25T21:00:34Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:\n\n> So I think the posted patch alone without changing anything else would be\n> the approach to give the most benefit with the least impact to existing\n> users, at least for now.\n\nYes, I meant to say in my original message but forgot to: I think\n--full-tree is an important first step, no matter what happens next. It\ngives people a way to do what they want without typing the right number\nof \"..\"s, and it opens up --no-full-tree if the default changes later.\n\nBut I do worry about it being a command-line option. You are asking the\nuser to remember to type --full-tree every time. I can't count the\nnumber of times I have been in a subdirectory and done \"git grep foo\",\nspent some time analyzing and doing something with the results, only for\nmy palm to hit my forehead when I realize that I was missing half of the\nresults I wanted. In other words, I not only have to remember to use the\noption, but when I forget, I may get punished very annoyingly by results\nwhich are subtly different from what I want.\n\nSo I am in favor of taking it further, but even if we do, the\ncommand-line option is the right thing to be doing _now_.\n\n> \"git grep -e frotz ..\" will work in your \"from linux/subproject/t look for\n> everywhere in linux/subproject\", but if \"/t\" part were much longer and\n> variable (iow you need to chdir around inside linux/subproject to scratch\n> your itch) compared to \"linux/subproject\" part that is much shorter and\n> static (to your work), it may make sense to give us a mode to specify\n> pathspec from the top of the tree.\n> \n> $ cd linux/subproject\n> $ cd foo\n> $ cd bar\n> $ cd baz\n> $ git grep --absolute-pathspec -e frotz -- linux/subproject\n> \n> As \"git grep\" never takes absolute paths, we _might_ be able to also do\n> \n> $ git grep -e frotz -- /linux/subproject\n> \n> to achieve the same.\n\nCertainly I think that would be an improvement. But again, it suffers\nfrom the \"you must remember to do this\" as above. I really want \"git\ngrep\" to Do What I Mean.\n\nI have to wonder: is \"git grep\" really plumbing or porcelain? It is\nreally just a wrapper for\n\n git ls-files | xargs grep\n\nDo people actually use it in their scripts? Should they be?\n\n-Peff\n"},{"id":"128345","messageId":"7vmy2as319.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091125210034.GC18487@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T21:33:22Z","receivedAt":"2009-11-25T21:33:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:\n>\n>> So I think the posted patch alone without changing anything else would be\n>> the approach to give the most benefit with the least impact to existing\n>> users, at least for now.\n>\n> Yes, I meant to say in my original message but forgot to: I think\n> --full-tree is an important first step, no matter what happens next. It\n> gives people a way to do what they want without typing the right number\n> of \"..\"s, and it opens up --no-full-tree if the default changes later.\n>\n> But I do worry about it being a command-line option. You are asking the\n> user to remember to type --full-tree every time.\n\nWe could redefine get_pathspec() to treat a pathspec that begins with a\nslash to be anchored at the top, i.e.\n\n\t$ git grep -e frotz /\n\nwould be a nicer way to spell\n\n\t$ git grep --full-tree -e frotz\n\nand allows you more than what you can do with --full-tree, e.g.\n\n\t$ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly\n\t$ git grep -e frotz /linux/subtree\n\nIf we do that, it will not be limited to \"grep\" but would bring uniformity\nto the command set [*1*]. Of course, you can keep doing\n\n\t$ cd t\n\t$ git grep -e frotz .\n\nto look inside only the current directory, and once this new convention is\naccepted and widely used, it would become possible to flip the default\nwithout causing too much pain (yes, I am agreeing with you that this is an\nimportant first step).\n\nOnce there is a convenient and uniform way to ask for either behaviour, no\nmatter what the default is, the scripts that want specific behaviour can\nbe updated to choose whichever they want, given enough time (say, 2.0.0).\n\n> Certainly I think that would be an improvement. But again, it suffers\n> from the \"you must remember to do this\" as above. I really want \"git\n> grep\" to Do What I Mean.\n\nAnd /this-is-absolute is one way to tell \"grep\" What You Mean. I do not\nclaim it would be the _best_ way (I just concocted it up a few minutes ago\nwithout giving it deep thought). Do you have a better alternative in\nmind?\n\n> I have to wonder: is \"git grep\" really plumbing or porcelain? It is\n> really just a wrapper for\n>\n> git ls-files | xargs grep\n>\n> Do people actually use it in their scripts? Should they be?\n\nThe issue is not necessarily \"scripts\", but \"what people use the output\nfor\".\n\nMy earlier \"push is excusable\" was primarily because \"push\" tends to be\nthe _final_ action in the chain of events, as opposed to \"ls-files\" and\n\"grep\" output that are meant to be used by the user to _decide_ what to\ndo next depending on what they find, and as such, the latter has more\nproblem if they changed behaviour based on the configuration.\n\n\n[Footnote]\n\n*1* It won't be only get_pathspec(), but we would also need to teach\nverify_filename() and verify_non_filename() about the new convention.\n"},{"id":"128347","messageId":"20091125214949.GA31473@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7vmy2as319.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T21:49:49Z","receivedAt":"2009-11-25T21:49:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 01:33:22PM -0800, Junio C Hamano wrote:\n\n> We could redefine get_pathspec() to treat a pathspec that begins with a\n> slash to be anchored at the top, i.e.\n> \n> \t$ git grep -e frotz /\n> \n> would be a nicer way to spell\n> \n> \t$ git grep --full-tree -e frotz\n\nI do like that idea (and I cannot see any obvious flaw in it, though I\nhave only been think for a few minutes). I am not sure how useful it\nwill be for other commands. Conceptually I might use it for \"diff\" and\n\"status\" (the new version that uses pathspecs sanely :) ), but those\ncommands generally aren't a big deal. I haven't touched anything in the\nuninteresting subtree, so there is nothing to report.\n\nHmm. Actually, after having considered that, don't we actually allow\nabsolute paths in diff to do out-of-tree diffs? I haven't looked at how\nthat code interacts with get_pathspec.\n\n> > Certainly I think that would be an improvement. But again, it suffers\n> > from the \"you must remember to do this\" as above. I really want \"git\n> > grep\" to Do What I Mean.\n> \n> And /this-is-absolute is one way to tell \"grep\" What You Mean. I do not\n> claim it would be the _best_ way (I just concocted it up a few minutes ago\n> without giving it deep thought). Do you have a better alternative in\n> mind?\n\nWell, what I meant is that I shouldn't have to tell it each time what I\nmean. I should be able to set up configuration so that it does what I\nwant (well, ideally, it would just read my mind, but I am willing to\nconcede that point). That is, I don't want to have to remember \"git grep\n--full-tree\" or \"git grep /\" every time, because I am not likely to\nnotice when I forget. I want to set up \"when I am in this directory,\nthis is probably what I want\".\n\n> My earlier \"push is excusable\" was primarily because \"push\" tends to be\n> the _final_ action in the chain of events, as opposed to \"ls-files\" and\n> \"grep\" output that are meant to be used by the user to _decide_ what to\n> do next depending on what they find, and as such, the latter has more\n> problem if they changed behaviour based on the configuration.\n\nI'm not sure I really understand. \"git grep\" is routinely producing\nwrong results for me _now_. I'd like to configure it so that it produces\nresults more sensible to me. If I am the one who sets the configuration\nvariable to something more sensible for my workflow, who am I hurting?\n\n-Peff\n"},{"id":"128349","messageId":"885649360911251412n3e566c8fu536b361b993f2ac6@mail.gmail.com","threadId":"21734","inReplyTo":"20091125214949.GA31473@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2009-11-25T22:12:26Z","receivedAt":"2009-11-25T22:12:26Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"On Wed, Nov 25, 2009 at 2:49 PM, Jeff King wrote:\n> I'm not sure I really understand. \"git grep\" is routinely producing\n> wrong results for me _now_. I'd like to configure it so that it produces\n> results more sensible to me. If I am the one who sets the configuration\n> variable to something more sensible for my workflow, who am I hurting?\n\nConfig options are not free - they add code bloat, increase the maintenance\nand testing burden, make it harder to explain how Git works if you have to\nsay things like \"if config X is true, then Git does ..., otherwise Git does\n..., unless config Y is false, in which case Git does ...\", make it harder\nto debug when Git doesn't do what you expected if you have to check a bunch\nof configs to figure out what the behavior should be, and make it harder to\ndevelop new features since you have to consider how they might interact with\nlots of config options. So I think the bar for adding config options,\nespecially ones that fundamentally change user visible behavior, should be\nset pretty high, and this one doesn't even come close to getting over the\nbar.\n\nI like Junio's suggestion to make paths starting with / anchored to the\ntop. If that were added then it would be easy for users to tell Git what\nthey want; they just have to use the right pathspec, which I think is a\nvery reasonable requirement.\n\nThat's my 2 cents....\n\nJames\n"},{"id":"128350","messageId":"4B0DAC9F.2010205@gmail.com","threadId":"21734","inReplyTo":"7vmy2as319.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-25T22:15:59Z","receivedAt":"2009-11-25T22:15:59Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n > Jeff King writes:\n >\n >> On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:\n >>\n >>> So I think the posted patch alone without changing anything else \nwould be\n >>> the approach to give the most benefit with the least impact to existing\n >>> users, at least for now.\n >> Yes, I meant to say in my original message but forgot to: I think\n >> --full-tree is an important first step, no matter what happens next. It\n >> gives people a way to do what they want without typing the right number\n >> of \"..\"s, and it opens up --no-full-tree if the default changes later.\n >>\n >> But I do worry about it being a command-line option. You are asking the\n >> user to remember to type --full-tree every time.\n >\n > We could redefine get_pathspec() to treat a pathspec that begins with a\n > slash to be anchored at the top, i.e.\n >\n > \t$ git grep -e frotz /\n >\n > would be a nicer way to spell\n >\n > \t$ git grep --full-tree -e frotz\n >\n > and allows you more than what you can do with --full-tree, e.g.\n >\n > \t$ cd linux/subtree/some/very/deep/subdir/you/do/not/remember/exactly\n > \t$ git grep -e frotz /linux/subtree\n >\n > If we do that, it will not be limited to \"grep\" but would bring \nuniformity\n > to the command set [*1*]. Of course, you can keep doing\n >\n > \t$ cd t\n > \t$ git grep -e frotz .\n >\n > to look inside only the current directory, and once this new \nconvention is\n > accepted and widely used, it would become possible to flip the default\n > without causing too much pain (yes, I am agreeing with you that this \nis an\n > important first step).\n >\n > Once there is a convenient and uniform way to ask for either \nbehaviour, no\n > matter what the default is, the scripts that want specific behaviour can\n > be updated to choose whichever they want, given enough time (say, 2.0.0).\n >\n\nSpeaking as a `grep' user: having git-grep behave radically different \nthan normal grep would be/is very annoying [*1*].\n\nSpeaking as a `git' user: having the different git commands use \nradically different path conventions, relative to other git commands, \nwould be/is very annoying [*1*].\n\nTo make the reconciliation even more difficult, some git commands will \nalso work on out-of-tree paths.\n\nFootnotes:\n[*1*] And surprising to new/occasional git users.\n"},{"id":"128351","messageId":"7vtywiqmbs.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091125214949.GA31473@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T22:19:35Z","receivedAt":"2009-11-25T22:19:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... That is, I don't want to have to remember \"git grep\n> --full-tree\" or \"git grep /\" every time\n\nBut that cuts both ways. If you change the default to full-tree,\npeople will forget to put \".\" every time when asking to limit to the\ncurrent directory.\n\n> If I am the one who sets the configuration variable to something more\n> sensible for my workflow, who am I hurting?\n\nSomebody more clueful in git than you who is called to help you in your\nrepository when you have trouble. Obviously \"you\" in this sentence is not\nJeff King, but I think you get the point.\n\nAnd re-read what I wrote in its entirety and notice I am not disagreeing\nwith you that the long term goal should be to have the default changed\nconsistently for all command to do the full tree. The important first\nstep is to make sure we are capable of doing both full tree and limit to\ncurrent directory and \"grep\" is one example that cannot do both, and be it\nthe --full-tree option or new /rooted-pathspec, we need some change _now_\nthat is backward compatible to pave the way for later changes. We give\npeople convenient way to choose between the two, and _train_ them to\nexpress which way they want _without_ having to think. After that is\nachieved, the default does not matter much and we can safely change the\ndefault.\n\nThink of it as a way to force existing users _unlearn_ the command\nspecific default we currently have. Because any change of default will\nhurt them until that is done, we should start training them as early as\npossible.\n"},{"id":"128352","messageId":"20091125222037.GA2861@coredump.intra.peff.net","threadId":"21734","inReplyTo":"885649360911251412n3e566c8fu536b361b993f2ac6@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T22:20:37Z","receivedAt":"2009-11-25T22:20:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 03:12:26PM -0700, James Pickens wrote:\n\n> Config options are not free - they add code bloat, increase the maintenance\n> and testing burden, make it harder to explain how Git works if you have to\n> say things like \"if config X is true, then Git does ..., otherwise Git does\n> ..., unless config Y is false, in which case Git does ...\", make it harder\n> to debug when Git doesn't do what you expected if you have to check a bunch\n> of configs to figure out what the behavior should be, and make it harder to\n> develop new features since you have to consider how they might interact with\n> lots of config options. So I think the bar for adding config options,\n> especially ones that fundamentally change user visible behavior, should be\n> set pretty high, and this one doesn't even come close to getting over the\n> bar.\n\nSure, there are all those downsides. But what is the other option?\nMaking me use the command line option (or pathspec magic) every single\ntime I invoke git grep? That is a huge downside to me.\n\nI started to try to write an argument against this, but I really don't\nknow how to. You don't think this particular option gets over the bar.\nProbably because it is not something that has been annoying you\npersonally. But is _is_ something that has been annoying me. Now we are\nboth making claims from our gut. How do we proceed with a rational\nanalysis?\n\n-Peff\n"},{"id":"128353","messageId":"7vljhuqm84.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"4B0DAC9F.2010205@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T22:21:47Z","receivedAt":"2009-11-25T22:21:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM writes:\n\n> To make the reconciliation even more difficult, some git commands\n> will also work on out-of-tree paths.\n\nI think people know my feeling towards \"diff --no-index\". It makes many\nnice features invented in git to people who do not use \"git\" (e.g, to\ncompare files outside of control of git using --color-words). If it\nhappened in an ideal world, it wouldn't have been done as a patch to \"git\"\nbut to something like \"GNU diff\" to benefit people who do not even want to\ninstall \"git\". But unfortunately that wasn't the way it was done.\n\nIt has turned out to be an unnecessary maintenance burden ever since it\nwas applied and every time we needed to change small things to \"git diff\".\nI would not be very unhappy if we need to ejected it from \"git diff\" if it\nturns out to hinder the necessary UI changes too much.\n"},{"id":"128355","messageId":"20091125222625.GB2861@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7vtywiqmbs.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T22:26:25Z","receivedAt":"2009-11-25T22:26:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ... That is, I don't want to have to remember \"git grep\n> > --full-tree\" or \"git grep /\" every time\n> \n> But that cuts both ways. If you change the default to full-tree,\n> people will forget to put \".\" every time when asking to limit to the\n> current directory.\n\nI know. Which is why I am arguing for a configuration option.\n\nThough as a side note, I think if you are going to err, it is probably\nbetter to err in showing _too much_ data. It is easier for the user to\nnotice the situation and re-issue the command with more limits than it\nis for them to notice that some results are missing and re-issue the\ncommand with fewer limits.\n\n> > If I am the one who sets the configuration variable to something more\n> > sensible for my workflow, who am I hurting?\n> \n> Somebody more clueful in git than you who is called to help you in your\n> repository when you have trouble. Obviously \"you\" in this sentence is not\n> Jeff King, but I think you get the point.\n\nClearly, because there _isn't_ anybody more clueful than me in git. ;)\n\nBut that is what my meta-rant elsewhere in the thread was about. Sure,\nit hurts when more clueful people are called in (and that includes\nasking for help on the list). But that evil to me is much less than a\nuser who is frustrated because they have to specify the same thing to\ngit over and over again.\n\n> And re-read what I wrote in its entirety and notice I am not disagreeing\n> with you that the long term goal should be to have the default changed\n> consistently for all command to do the full tree. The important first\n> step is to make sure we are capable of doing both full tree and limit to\n> current directory and \"grep\" is one example that cannot do both, and be it\n> the --full-tree option or new /rooted-pathspec, we need some change _now_\n> that is backward compatible to pave the way for later changes. We give\n> people convenient way to choose between the two, and _train_ them to\n> express which way they want _without_ having to think. After that is\n> achieved, the default does not matter much and we can safely change the\n> default.\n> \n> Think of it as a way to force existing users _unlearn_ the command\n> specific default we currently have. Because any change of default will\n> hurt them until that is done, we should start training them as early as\n> possible.\n\nI agree with all of this as far as changing the default goes. But the\npoint of my earlier messages was that I don't think there _is_ one sane\ndefault. I really do want it different per-project. And that means a\nconfiguration option.\n\n-Peff\n"},{"id":"128362","messageId":"60F92BD7-6FFF-4D9A-B2F0-0858F4E90B59@wincent.com","threadId":"21734","inReplyTo":"885649360911251412n3e566c8fu536b361b993f2ac6@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-11-25T22:26:27Z","receivedAt":"2009-11-25T22:26:27Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 25/11/2009, a las 23:12, James Pickens escribió:\n\n> I like Junio's suggestion to make paths starting with / anchored to \n> the\n> top.\n\nOh, I wouldn't like that at all. I think it would be a very ugly UI \nwart, because it would basically make Git behave differently than \nevery other command line tool that accepts paths. If it is to deviate \nfrom the extremely widespread convention that paths starting with / \nrefer to absolute paths rooted at the root of the filesystem, then the \njustification for it would need to be very strong indeed.\n\nCheers,\nWincent\n"},{"id":"128356","messageId":"4B0DB04A.6020209@gmail.com","threadId":"21734","inReplyTo":"7vljhuqm84.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-25T22:31:38Z","receivedAt":"2009-11-25T22:31:38Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> A Large Angry SCM writes:\n> \n>> To make the reconciliation even more difficult, some git commands\n>> will also work on out-of-tree paths.\n> \n> I think people know my feeling towards \"diff --no-index\". It makes many\n> nice features invented in git to people who do not use \"git\" (e.g, to\n> compare files outside of control of git using --color-words). If it\n> happened in an ideal world, it wouldn't have been done as a patch to \"git\"\n> but to something like \"GNU diff\" to benefit people who do not even want to\n> install \"git\". But unfortunately that wasn't the way it was done.\n> \n> It has turned out to be an unnecessary maintenance burden ever since it\n> was applied and every time we needed to change small things to \"git diff\".\n> I would not be very unhappy if we need to ejected it from \"git diff\" if it\n> turns out to hinder the necessary UI changes too much.\n> \n\ngit-diff aside, I would be much happier with git's interface, and I \nthink new/occasional users would be also, if it was consistent across \nall of git commands. And even more so if git's conventions matched most \nother commands on my system of choice.\n"},{"id":"128357","messageId":"4B0DB29D.5010101@gmail.com","threadId":"21734","inReplyTo":"20091125222625.GB2861@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-25T22:41:33Z","receivedAt":"2009-11-25T22:41:33Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jeff King wrote:\n> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:\n> \n>> Jeff King writes:\n>>\n>>> ... That is, I don't want to have to remember \"git grep\n>>> --full-tree\" or \"git grep /\" every time\n>> But that cuts both ways. If you change the default to full-tree,\n>> people will forget to put \".\" every time when asking to limit to the\n>> current directory.\n> \n> I know. Which is why I am arguing for a configuration option.\n> \n> Though as a side note, I think if you are going to err, it is probably\n> better to err in showing _too much_ data. It is easier for the user to\n> notice the situation and re-issue the command with more limits than it\n> is for them to notice that some results are missing and re-issue the\n> command with fewer limits.\n> \n>>> If I am the one who sets the configuration variable to something more\n>>> sensible for my workflow, who am I hurting?\n>> Somebody more clueful in git than you who is called to help you in your\n>> repository when you have trouble. Obviously \"you\" in this sentence is not\n>> Jeff King, but I think you get the point.\n> \n> Clearly, because there _isn't_ anybody more clueful than me in git. ;)\n> \n> But that is what my meta-rant elsewhere in the thread was about. Sure,\n> it hurts when more clueful people are called in (and that includes\n> asking for help on the list). But that evil to me is much less than a\n> user who is frustrated because they have to specify the same thing to\n> git over and over again.\n> \n>> And re-read what I wrote in its entirety and notice I am not disagreeing\n>> with you that the long term goal should be to have the default changed\n>> consistently for all command to do the full tree. The important first\n>> step is to make sure we are capable of doing both full tree and limit to\n>> current directory and \"grep\" is one example that cannot do both, and be it\n>> the --full-tree option or new /rooted-pathspec, we need some change _now_\n>> that is backward compatible to pave the way for later changes. We give\n>> people convenient way to choose between the two, and _train_ them to\n>> express which way they want _without_ having to think. After that is\n>> achieved, the default does not matter much and we can safely change the\n>> default.\n>>\n>> Think of it as a way to force existing users _unlearn_ the command\n>> specific default we currently have. Because any change of default will\n>> hurt them until that is done, we should start training them as early as\n>> possible.\n> \n> I agree with all of this as far as changing the default goes. But the\n> point of my earlier messages was that I don't think there _is_ one sane\n> default. I really do want it different per-project. And that means a\n> configuration option.\n\nSince grep is so useful, both interactively and scripted, outside of \ngit, this is a pretty convincing argument that git-grep, and all other \ngit commands with configurable behavior or defaults that change over \ntime, need a both a scripting form and an interactive form.\n"},{"id":"128358","messageId":"4B0DB319.6000805@gmail.com","threadId":"21734","inReplyTo":"4B0DB04A.6020209@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-25T22:43:37Z","receivedAt":"2009-11-25T22:43:37Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"A Large Angry SCM wrote:\n> git-diff aside, I would be much happier with git's interface, and I \n> think new/occasional users would be also, if it was consistent across \n> all of git commands. And even more so if git's conventions matched most \n> other commands on my system of choice.\n\ns/my system of choice/the user's system of choice/\n"},{"id":"128361","messageId":"20091125225318.GA10127@coredump.intra.peff.net","threadId":"21734","inReplyTo":"4B0DB29D.5010101@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T22:53:19Z","receivedAt":"2009-11-25T22:53:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:\n\n> >I agree with all of this as far as changing the default goes. But the\n> >point of my earlier messages was that I don't think there _is_ one sane\n> >default. I really do want it different per-project. And that means a\n> >configuration option.\n> \n> Since grep is so useful, both interactively and scripted, outside of\n> git, this is a pretty convincing argument that git-grep, and all\n> other git commands with configurable behavior or defaults that change\n> over time, need a both a scripting form and an interactive form.\n\nIt is tempting to have scripts simply set a GIT_VANILLA environment\nvariable to ignore config options. But I think it is not quite so\nsimple. As a script, if I am calling \"git log\", do I want it to respect\nthe user's colorization config or not? It depends on _how_ I am calling\nit. Is the output to be shown to the user, or am I going to process it\nmyself?\n\nSimilarly, why is the script calling \"git grep\"? If it is because the\nscript is a convenience wrapper (e.g., let's say to colorize the output\nin a particular way), then it probably wants to respect my configured\nchoice of which files to grep. But if the script is just using \"git\ngrep\" to get data to perform some other calculation, then it probably\ndoes care deeply about which set of files to grep.\n\nSo I think you have situations where scripts do want to invoke the\nporcelain version of a command versus the plumbing. But much harder, you\nhave ones where they want to respect some options but not others.\n\n-Peff\n"},{"id":"128364","messageId":"4B0DB894.7010800@gmail.com","threadId":"21734","inReplyTo":"20091125225318.GA10127@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-25T23:07:00Z","receivedAt":"2009-11-25T23:07:00Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jeff King wrote:\n> On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:\n> \n>>> I agree with all of this as far as changing the default goes. But the\n>>> point of my earlier messages was that I don't think there _is_ one sane\n>>> default. I really do want it different per-project. And that means a\n>>> configuration option.\n>> Since grep is so useful, both interactively and scripted, outside of\n>> git, this is a pretty convincing argument that git-grep, and all\n>> other git commands with configurable behavior or defaults that change\n>> over time, need a both a scripting form and an interactive form.\n> \n> It is tempting to have scripts simply set a GIT_VANILLA environment\n> variable to ignore config options. But I think it is not quite so\n> simple. As a script, if I am calling \"git log\", do I want it to respect\n> the user's colorization config or not? It depends on _how_ I am calling\n> it. Is the output to be shown to the user, or am I going to process it\n> myself?\n> \n> Similarly, why is the script calling \"git grep\"? If it is because the\n> script is a convenience wrapper (e.g., let's say to colorize the output\n> in a particular way), then it probably wants to respect my configured\n> choice of which files to grep. But if the script is just using \"git\n> grep\" to get data to perform some other calculation, then it probably\n> does care deeply about which set of files to grep.\n> \n> So I think you have situations where scripts do want to invoke the\n> porcelain version of a command versus the plumbing. But much harder, you\n> have ones where they want to respect some options but not others.\n\n\nSo, what's the solution?\n\nHave every command command take a list of configuration options to \nignore/respect?\n\nHave every command take an option to ignore/respect _all_ configuration \noptions?\n\nHave inconsistency between commands, like we have now\n\nHave commands have all kinds of hidden/undocumented default settings?\n\n"},{"id":"128367","messageId":"20091125232210.GA15538@coredump.intra.peff.net","threadId":"21734","inReplyTo":"4B0DB894.7010800@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-25T23:22:10Z","receivedAt":"2009-11-25T23:22:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 06:07:00PM -0500, A Large Angry SCM wrote:\n\n> \n> So, what's the solution?\n> \n> Have every command command take a list of configuration options to\n> ignore/respect?\n> \n> Have every command take an option to ignore/respect _all_\n> configuration options?\n> \n> Have inconsistency between commands, like we have now\n> \n> Have commands have all kinds of hidden/undocumented default settings?\n> \n\nI don't know. All of those options suck. ;\n\nProbably we would want something flexible, but with sane defaults. Like\nan environment variable to ignore all (or most) config options, but then\nthe ability to opt into specific ones. Something like:\n\n GIT_PLUMBING=1; export GIT_PLUMBING\n git log ;# does not respect any non-plumbing config\n git --respect='log.showroot' ;# respect just the one variable\n git --respect='color.*' log ;# you get all color\n\nBut there are two big obstacles (besides the obvious issue that\nintroducing this in itself needs a gentle transition plan):\n\n 1. We need to annotate every config option with whether it is\n potentially problematic. For example, core.filemode should probably\n be respected no matter what (but I'm not sure if it is simply true\n for core.*).\n\n 2. Script writers need to actually use the system, which is somewhat\n more verbose and annoying than what they have to do now. But at\n least it defaults to safety when they are lazy, and then they can\n re-add options. Of course, they are stuck on an upgrade treadmill\n of analyzing and approving each new option that appears in git.\n\n-Peff\n"},{"id":"128370","messageId":"fabb9a1e0911251529v2f4a3426rcc6b79cfb567df18@mail.gmail.com","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911260030130.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] grep: --full-tree","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-25T23:29:54Z","receivedAt":"2009-11-25T23:29:54Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Nov 26, 2009 at 00:31, Johannes Schindelin\n wrote:\n> You mean like the many people who wanted to keep the dashed commands, but\n> unlike who you do speak up _before_ your expectations are broken?\n\nYes, kinda like that, but with the note that I do think we should not\nlock down the UI in favor or not breaking expectations. I mean, if\npeople want to retain a specific behavior forever, maybe they should\njust keep using that version of git forever? Nah, that doens't work of\ncourse, but I do think a balance is needed between the two (improving\nthe UI and not breaking people's expectations).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128368","messageId":"alpine.DEB.1.00.0911260030130.4985@pacific.mpi-cbg.de","threadId":"21734","inReplyTo":"fabb9a1e0911251246l4684f357pb5f379b191aaa64a@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-25T23:31:04Z","receivedAt":"2009-11-25T23:31:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Nov 2009, Sverre Rabbelier wrote:\n\n> On Wed, Nov 25, 2009 at 21:23, Junio C Hamano wrote:\n> > But then you can alias \"gr 'grep --full-tree'\" with the same ease and \n> > there is no reason to change the default.\n> \n> I agree, but then again I'm somewhat biased, as I want the current \n> behavior :P.\n\nYou mean like the many people who wanted to keep the dashed commands, but \nunlike who you do speak up _before_ your expectations are broken?\n\nCiao,\nDscho\n"},{"id":"128371","messageId":"alpine.DEB.1.00.0911260032410.4985@pacific.mpi-cbg.de","threadId":"21734","inReplyTo":"7vmy2as319.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-25T23:34:49Z","receivedAt":"2009-11-25T23:34:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Nov 2009, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:\n> >\n> >> So I think the posted patch alone without changing anything else would be\n> >> the approach to give the most benefit with the least impact to existing\n> >> users, at least for now.\n> >\n> > Yes, I meant to say in my original message but forgot to: I think\n> > --full-tree is an important first step, no matter what happens next. It\n> > gives people a way to do what they want without typing the right number\n> > of \"..\"s, and it opens up --no-full-tree if the default changes later.\n> >\n> > But I do worry about it being a command-line option. You are asking the\n> > user to remember to type --full-tree every time.\n> \n> We could redefine get_pathspec() to treat a pathspec that begins with a\n> slash to be anchored at the top,\n\nThis would break spectacularly in MSys. And this is just one reason not \nto do this \"magic\".\n\nClearly, a command line option is the only unambiguous way to do what you \nwant to do (and not changing the default all of a sudden).\n\nCiao,\nDscho\n"},{"id":"128372","messageId":"7vvdgyp3zn.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911260032410.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-25T23:41:00Z","receivedAt":"2009-11-25T23:41:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> This would break spectacularly in MSys.\n\nHow? If that is the case wouldn't --full-tree break Msys the same way?\n"},{"id":"128378","messageId":"7vd436p339.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"60F92BD7-6FFF-4D9A-B2F0-0858F4E90B59@wincent.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T00:00:26Z","receivedAt":"2009-11-26T00:00:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta writes:\n\n> Oh, I wouldn't like that at all. I think it would be a very ugly UI\n> wart, because it would basically make Git behave differently than\n> every other command line tool that accepts paths. If it is to deviate\n> from the extremely widespread convention that paths starting with /\n> refer to absolute paths rooted at the root of the filesystem, then the\n> justification for it would need to be very strong indeed.\n\nThere are at least two flaws in that argument.\n\n - git does not accept paths (it lets you specify patterns that match,\n e.g. t/ to name ptahs under t/ directory).\n\n - \"/pathspec\" does follow the widespread convention that a string that\n begin with a \"/\" refer to a path rooted at the root _in the context_;\n the definition of root may or may not match the filesystem root.\n\n Think of things like Top. Does \"/$path\" mean at\n the root of filesystem? No.\n\nI am not married to the \"git grep -e frotz /Documentation\" notation, by\nthe way. I just didn't think of a different notation that is equally\nshort, sweet and logical. We could do //Documentation if it makes it more\ndistinct, but I do think it is worse than a single slash.\n"},{"id":"128379","messageId":"7v8wdup2z2.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091125222625.GB2861@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T00:02:57Z","receivedAt":"2009-11-26T00:02:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > ... That is, I don't want to have to remember \"git grep\n>> > --full-tree\" or \"git grep /\" every time\n>> \n>> But that cuts both ways. If you change the default to full-tree,\n>> people will forget to put \".\" every time when asking to limit to the\n>> current directory.\n>\n> I know. Which is why I am arguing for a configuration option.\n\nYeah; what is your take on tr/reset-checkout-patch topic, by the way? I\ndo not particularly like a configuration that changes the behaviour of a\ncommand in a drastic way---it will make helping others much harder, but I\nguess it should be Ok?\n\nThis may sound like an OffTopic, but because we _are_ discussing\nconsistency, it matters.\n"},{"id":"128377","messageId":"alpine.DEB.1.00.0911260059040.4985@pacific.mpi-cbg.de","threadId":"21734","inReplyTo":"7vvdgyp3zn.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-26T00:04:04Z","receivedAt":"2009-11-26T00:04:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Nov 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > This would break spectacularly in MSys.\n> \n> How? If that is the case wouldn't --full-tree break Msys the same way?\n\nIf you want to specify an argument on MSys that starts with a slash, you \nhave to provide double slashes, otherwise it gets expanded to the Windows \npath (prefixing with the absolute path of the MSys root).\n\nBut this introduces yet another inconcistency: using double slashes \neverywhere else does not work.\n\nHopefully you see the real reason why it breaks down? The reason is that \nyou try to re-interpret something in a special way that means something \ndifferent. A path starting with a slash simply does not mean \"the root of \nthe project\". It means \"the root of the file system\".\n\nCiao,\nDscho\n"},{"id":"128380","messageId":"7vzl6annwm.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911260059040.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T00:13:45Z","receivedAt":"2009-11-26T00:13:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> If you want to specify an argument on MSys that starts with a slash, you \n> have to provide double slashes, otherwise it gets expanded to the Windows \n> path (prefixing with the absolute path of the MSys root).\n\nHow well does the command line hack handle things like\n\n $ git archive --output=/var/tmp/foo.tar\n\nI have to wonder.\n\n> Hopefully you see the real reason why it breaks down?\n\nYes, Windows' braindamage. It doesn't invalidate anything I said so far,\nbut only proves that emulation can go only so far. I hope msys port can\ngrok real \"path from root\" notation on Windows, e.g.\n\n $ git diff --no-index \"C:\\My Documents/hello.txt\" \"D:\\goodbye.txt\"\n\n(or perhaps \"//c/my documents/...\", but I do not care about the details).\n"},{"id":"128381","messageId":"4B0DC8F7.1000509@gmail.com","threadId":"21734","inReplyTo":"7vd436p339.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-26T00:16:55Z","receivedAt":"2009-11-26T00:16:55Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n> - git does not accept paths (it lets you specify patterns that match,\n> e.g. t/ to name ptahs under t/ directory).\n\nHere is where it get interesting!\n\nOur users, new and old alike, are wanting consistency. Consistency \namongst the git commands. Consistency with their platform of choice. \nConsistency with what they are familiar with, Consistency with their \nexpectations.\n\nDeclaring that git commands (all?!) do not take paths but patterns does \nnot help the situation; however technically correct it may be.\n\n> - \"/pathspec\" does follow the widespread convention that a string that\n> begin with a \"/\" refer to a path rooted at the root _in the context_;\n> the definition of root may or may not match the filesystem root.\n\nBut the users are almost always dealing with things (objects) that \nstarted as files, act like files and may be files again. Why should they \nnot expect filesystem semantics.\n"},{"id":"128382","messageId":"7v4ooinnkx.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"4B0DC8F7.1000509@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T00:20:46Z","receivedAt":"2009-11-26T00:20:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM writes:\n\n> But the users are almost always dealing with things (objects) that\n> started as files, act like files and may be files again. Why should\n> they not expect filesystem semantics.\n\nDo you truly want to see this?\n\n diff --git a/var/tmp/git/Makefile b/var/tmp/git/Makefile\n index 5a0b3d4..e9b03a8 100644\n --- a/var/tmp/git/Makefile\n +++ b/var/tmp/git/Makefile\n @@ -1985,3 +1985,4 @@ coverage-report:\n ...\n\nAs long as you are talking about paths you communicate with git, your\nroot _is_ the root of the work tree, and it shouldn't matter where you\nhave your work tree.\n\nThat is what I meant by \"the root _in the context_\".\n"},{"id":"128383","messageId":"4B0DCC27.4030702@gmail.com","threadId":"21734","inReplyTo":"7v4ooinnkx.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-26T00:30:31Z","receivedAt":"2009-11-26T00:30:31Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> A Large Angry SCM writes:\n> \n>> But the users are almost always dealing with things (objects) that\n>> started as files, act like files and may be files again. Why should\n>> they not expect filesystem semantics.\n> \n> Do you truly want to see this?\n> \n> diff --git a/var/tmp/git/Makefile b/var/tmp/git/Makefile\n> index 5a0b3d4..e9b03a8 100644\n> --- a/var/tmp/git/Makefile\n> +++ b/var/tmp/git/Makefile\n> @@ -1985,3 +1985,4 @@ coverage-report:\n> ...\n> \n> As long as you are talking about paths you communicate with git, your\n> root _is_ the root of the work tree, and it shouldn't matter where you\n> have your work tree.\n> \n> That is what I meant by \"the root _in the context_\".\n> \n\nNice example for a command output. But what did the user specify on the \ncommand line?\n"},{"id":"128385","messageId":"7vd436m8af.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"4B0DCC27.4030702@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T00:36:24Z","receivedAt":"2009-11-26T00:36:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM writes:\n\n> Junio C Hamano wrote:\n>> A Large Angry SCM writes:\n>>\n>>> But the users are almost always dealing with things (objects) that\n>>> started as files, act like files and may be files again. Why should\n>>> they not expect filesystem semantics.\n>>\n>> Do you truly want to see this?\n>>\n>> diff --git a/var/tmp/git/Makefile b/var/tmp/git/Makefile\n>> index 5a0b3d4..e9b03a8 100644\n>> --- a/var/tmp/git/Makefile\n>> +++ b/var/tmp/git/Makefile\n>> @@ -1985,3 +1985,4 @@ coverage-report:\n>> ...\n>>\n>> As long as you are talking about paths you communicate with git, your\n>> root _is_ the root of the work tree, and it shouldn't matter where you\n>> have your work tree.\n>>\n>> That is what I meant by \"the root _in the context_\".\n>\n> Nice example for a command output. But what did the user specify on\n> the command line?\n\nEither relative path from $(cwd) or full pathname from the root of the\nfilesystem in your world (because you do not understand the value of the\ncontext), and ralative path from $(cwd) or full pathname from the root of\nthe work tree in my world.\n"},{"id":"128484","messageId":"885649360911260956p58c54a54rd887102c9adedcc9@mail.gmail.com","threadId":"21734","inReplyTo":"20091125222037.GA2861@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2009-11-26T17:56:55Z","receivedAt":"2009-11-26T17:56:55Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"On Wed, Nov 25, 2009 at 3:20 PM, Jeff King wrote:\n> Sure, there are all those downsides. But what is the other option?\n> Making me use the command line option (or pathspec magic) every single\n> time I invoke git grep?\n\nYes, but only when you want non-default behavior, not every single time.\n\n> That is a huge downside to me.\n\nIs it *really*? Does it also bother you that you have to tell standalone\nunix commands like diff and grep what you want them to diff or grep every\nsingle time you invoke them?\n\n> I started to try to write an argument against this, but I really don't\n> know how to. You don't think this particular option gets over the bar.\n> Probably because it is not something that has been annoying you\n> personally. But is _is_ something that has been annoying me. Now we are\n> both making claims from our gut. How do we proceed with a rational\n> analysis?\n\nI really think that this config option wouldn't even help you, because\nyou'll have to remember what that option is set to in each working repo,\nand type the right command based on the setting. That seems worse than\nhaving to use the same options over and over again, which you probably use\nthe shell's history for anyways and don't actually type the same stuff over\nand over. Oh and you also have to remember to set the option in each new\nrepo you create.\n\nIf you can get the behavior you want using an alias or a script, then I\nsuggest you do that. I don't think this config option should be considered\nunless *many* people want it, and so far I count only 1.\n\nJames\n"},{"id":"128485","messageId":"885649360911261014w4f3a6150w31fe435c25065a2f@mail.gmail.com","threadId":"21734","inReplyTo":"7vd436p339.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"James Pickens","fromEmail":"jepicken@gmail.com","sentAt":"2009-11-26T18:14:49Z","receivedAt":"2009-11-26T18:14:49Z","isPatch":true,"sender":{"key":"jepicken@gmail.com","avatar":null},"body":"On Wed, Nov 25, 2009 at 5:00 PM, Junio C Hamano wrote:\n> - git does not accept paths (it lets you specify patterns that match,\n> e.g. t/ to name ptahs under t/ directory).\n\nThat's not entirely true, unfortunately:\n\n$ echo >> unpack-trees.c\n$ git diff --name-status unpack-trees.c\nM unpack-trees.c\n$ git diff --name-status $PWD/unpack-trees.c\nM unpack-trees.c\n$ git diff --name-status $PWD/../git/unpack-trees.c\nM unpack-trees.c\n$ git diff --name-status ../git/unpack-trees.c\nfatal: '../git/unpack-trees.c' is outside repository\n\nSo it seems that 'git diff' accepts absolute paths as long as they end up\nin the repository, but oddly enough, doesn't do so for relative paths.\nIt's possible that some users have scripts that use absolute paths, and\nchanging the interpretation would break those scripts. Such scripts\n*should* be rare, so maybe it's ok to break them, but it needs to be\nconsidered.\n\nJames\n"},{"id":"128526","messageId":"20091127062013.GA20844@coredump.intra.peff.net","threadId":"21734","inReplyTo":"885649360911260956p58c54a54rd887102c9adedcc9@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T06:20:13Z","receivedAt":"2009-11-27T06:20:13Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 26, 2009 at 10:56:55AM -0700, James Pickens wrote:\n\n> On Wed, Nov 25, 2009 at 3:20 PM, Jeff King wrote:\n> > Sure, there are all those downsides. But what is the other option?\n> > Making me use the command line option (or pathspec magic) every single\n> > time I invoke git grep?\n> \n> Yes, but only when you want non-default behavior, not every single time.\n\nDid you miss the part of the thread where I explained that in certain\nrepos, I want it one way every single time, and in others, I want it the\nother way?\n\nSo yes, in certain repos, it really is every single time.\n\n> > That is a huge downside to me.\n> \n> Is it *really*? Does it also bother you that you have to tell standalone\n> unix commands like diff and grep what you want them to diff or grep every\n> single time you invoke them?\n\nThis is a strawman. I am not saying every command-line option should be\nmade into a configuration option. I am saying that some options,\nincluding this one, would be useful as configuration options. I have\nalready explained several times in this thread exactly what\ncharacteristics of this option make that so.\n\nAnd please, questions like \"Is it *really*?\" don't add anything. Yes,\nreally, or I wouldn't be having this discussion. This behavior has\nbitten me many times while using \"git grep\". I'm not making it up. Maybe\nI am the only one in the world, but I don't see how it makes any sense\nto argue that I am not actually annoyed by it.\n\n> I really think that this config option wouldn't even help you, because\n> you'll have to remember what that option is set to in each working repo,\n> and type the right command based on the setting. That seems worse than\n\nNo, the _point_ is that I don't have to remember the right command in\neach repo. I can set it up for the workflow that matches that repository\nand then issue \"git grep\" without remembering which type I'm in.\n\n> If you can get the behavior you want using an alias or a script, then I\n> suggest you do that. I don't think this config option should be considered\n> unless *many* people want it, and so far I count only 1.\n\nPerhaps I am the only one who wants to use the config option per-repo.\nBut we have already seen support for both behaviors, which means there\nare people who will be dissatisfied with either simply leaving the\ndefault or changing the default. And I don't want to speak for Junio,\nbut he seemed to agree that what you most want would depend on the repo\norganization (though I think he may disagree that it is important enough\nto merit the hassle of a config option).\n\n-Peff\n"},{"id":"128527","messageId":"20091127062203.GB20844@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7v8wdup2z2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T06:22:04Z","receivedAt":"2009-11-27T06:22:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 25, 2009 at 04:02:57PM -0800, Junio C Hamano wrote:\n\n> Yeah; what is your take on tr/reset-checkout-patch topic, by the way? I\n> do not particularly like a configuration that changes the behaviour of a\n> command in a drastic way---it will make helping others much harder, but I\n> guess it should be Ok?\n> \n> This may sound like an OffTopic, but because we _are_ discussing\n> consistency, it matters.\n\nIt is near the top of my to-review queue. Honestly, despite any\narguments I may have made when the original reset/checkout -p series was\nposted, I have been pretty happy with the current behavior. I'll take a\nlook now and respond in more detail in that thread.\n\n-Peff\n"},{"id":"128542","messageId":"7vd434v0rm.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091127062013.GA20844@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T08:18:37Z","receivedAt":"2009-11-27T08:18:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... And I don't want to speak for Junio,\n> but he seemed to agree that what you most want would depend on the repo\n> organization (though I think he may disagree that it is important enough\n> to merit the hassle of a config option).\n\nOh, I totally agree with you that what's convenient is different per\n pair.\n\nIn my day-job project, I almost always work in a directory four levels\ndown from the toplevel (\"src/lib/u/\") and almost always what to\nrun grep from near the top (\"/src\" in the strawman syntax to grep from\nthat directory). I have similar preference when playing with projects I\nam not very familiar with---hack in a limited area somewhere deeper, but\ngrep a lot more widely. So it is very tempting to say that I would want\n\"full-tree\" configured as default in these repositories.\n\nBut the conclusion I draw from that observation is that it should be\nequally easy for me to invoke both behaviours from the command line, and\nnot \"I want to freeze which default is used for the project by setting a\nconfiguration variable\", because I know \"the role I play\" part changes\nfrom time to time (note that I didn't say \"changes over time\"---that can\nbe addressed by \"Then you should flip the config when the day comes\").\n\nAt first sight, git.git is too shallow for \"full-tree\" vs \"current\ndirectory\" distinction to make any meaningful difference, especially\nbecause it is very top heavy and I almost always am at the top level\ndirectory. But even there, I can clearly see that I have need for easy\naccess to both modes. I sometimes play a contributor who is interested in\nand is very familiar with a specific area (hence I know in which files to\nfind strings without resorting to full-tree grep), and other times play a\nreviewer role who tries to follow what an area expert, who is much more\nfamiliar than me in some parts of the system, did in his patch. In the\nlatter case, I would not know in which files to grep offhand, and would\nbenefit from \"tree-wide\" option, in order to find out what is done by that\nobscure function the area expert used in his patch.\n\nA repository-wide configuration would not help me at all, but a way to\ninvoke either mode from the command line that is short-and-sweet would\nconsistently give me the desired result without having to remember what\nthe default-of-the-day (or default-in-the-repo) is.\n\nBut the above is mostly about \"Peff wants config, Junio thinks it won't\nhelp him\", and is not really a disagreement. As long as we don't use the\nexistence of configurable defaults as an excuse for making/leaving it very\ncumbersome to invoke the non-default mode from command line, \"it won't\nhelp some users\" is not a reason to block it.\n\nI suspect a per-repo configuration _might_ confuse new people (and people\nwho help them), and I brought it up as a potential issue myself. That\ncould be a more valid reason to object to configurable default, but I\nhaven't formed an opinion how serious a problem it would be in real life;\nI should sleep on this one and wait for others' opinions.\n\nRegardless of the above, there are unresolved issues in the --full-tree\npatch as posted.\n\nWe've been saying that even if the default were changed to grep in the\nfull tree, limiting to the current directory is easy with a single \".\" at\nthe end, but I do not think it is entirely true. I often want to grep in\nonly \"*.h\" files but they are spread across the directories. If you do\n\n $ git grep -e frotz -- \"*.h\"\n\nit finds in paths that match the pathspec in the current directory with\ntoday's default, but after we flip the default (either globally or with\nyour configuration per-repo), it won't be possible to limit the search to\nheader files in the current directory and under. It will find in header\nfiles spread over in the whole tree.\n\nAlso the --full-tree option I did at the beginning of this thread doesn't\nwork with the above command line example, as it only kicks in when there\nis no pathspec.\n\nMaybe these are not worth solving, and we should keep the current default\nand just tell ourselves to go up to the level we want to grep from. That\nwould be simple, robust and the easiest to explain.\n"},{"id":"128551","messageId":"alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302","threadId":"21734","inReplyTo":"20091127062013.GA20844@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-27T09:31:30Z","receivedAt":"2009-11-27T09:31:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Nov 2009, Jeff King wrote:\n\n> On Thu, Nov 26, 2009 at 10:56:55AM -0700, James Pickens wrote:\n> \n> > On Wed, Nov 25, 2009 at 3:20 PM, Jeff King wrote:\n> > > Sure, there are all those downsides. But what is the other option? \n> > > Making me use the command line option (or pathspec magic) every \n> > > single time I invoke git grep?\n> > \n> > Yes, but only when you want non-default behavior, not every single \n> > time.\n> \n> Did you miss the part of the thread where I explained that in certain \n> repos, I want it one way every single time, and in others, I want it the \n> other way?\n\nGuess what. I have a similar problem, only it is that my \"git status\" \noutput is _always_ too long, so I always have to page it.\n\nOnce upon a time, Junio applied a patch that implied -p with status. I \nwas overjoyed. He reverted that patch later. Yes, exactly.\n\nSo I end up doing \"git config --global ps '-p status'\" on every new \naccount (I usually even forget to curse!), and I really cannot see why you \ndo not do the equivalent \"git config fullgrep grep --full-tree\" in your \nrepositories (or even the global thing).\n\nThe further benefit is that we stop talking about breaking backwards \ncompatibility, and we stop talking about making it hard for Git experts to \nhelp newbies.\n\nCiao,\nDscho\n"},{"id":"128553","messageId":"20091127095914.GA4865@sigill.intra.peff.net","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T09:59:14Z","receivedAt":"2009-11-27T09:59:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:\n\n> Guess what. I have a similar problem, only it is that my \"git status\" \n> output is _always_ too long, so I always have to page it.\n> \n> Once upon a time, Junio applied a patch that implied -p with status. I \n> was overjoyed. He reverted that patch later. Yes, exactly.\n> \n> So I end up doing \"git config --global ps '-p status'\" on every new \n\nIf only somebody had written a \"pager.status\" configuration variable,\nyou could use that. Oh wait. I did. And it shipped in v1.6.0.\n\n> account (I usually even forget to curse!), and I really cannot see why you \n> do not do the equivalent \"git config fullgrep grep --full-tree\" in your \n> repositories (or even the global thing).\n>\n> The further benefit is that we stop talking about breaking backwards \n> compatibility, and we stop talking about making it hard for Git experts to \n> help newbies.\n\nI guess you missed the part of the thread where I already discussed\nthis. It was here:\n\n http://article.gmane.org/gmane.comp.version-control.git/133672\n\n-Peff\n"},{"id":"128557","messageId":"vpq8wdsqmm4.fsf@bauges.imag.fr","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911271027510.4521@intel-tinevez-2-302","subject":"Re: [PATCH] grep: --full-tree","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-11-27T10:37:55Z","receivedAt":"2009-11-27T10:37:55Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n> Guess what. I have a similar problem, only it is that my \"git status\" \n> output is _always_ too long, so I always have to page it.\n>\n> Once upon a time, Junio applied a patch that implied -p with status. I \n> was overjoyed. He reverted that patch later. Yes, exactly.\n\nIn this particular example, a config variable was added (pager.status\n= true). But one big difference is that while pager.status = true can\nbe /annoying/ for some users, it can never really harm (since the\npager will automatically disable itself in the cases where you'd\nreally don't want it).\n\nOTOH, a config variable that actually changes the beahvior of the\ncommand can indeed harm. Those who ever tried doing portable\nprogramming in PHP, where the apache config can actually change the\nsemantics of the language probably understand what I mean ;-).\n\n> So I end up doing \"git config --global ps '-p status'\" on every new \n> account (I usually even forget to curse!), and I really cannot see why you \n> do not do the equivalent \"git config fullgrep grep --full-tree\" in your \n> repositories (or even the global thing).\n\n(I guess you meant alias.fullgrep)\n\nMaybe \"mygrep\" or \"dwimgrep\" would be a better name, except for the\ndifficulty to type it: the same alias can be defined to different\nthings on different machines.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"128558","messageId":"alpine.DEB.1.00.0911271144230.4521@intel-tinevez-2-302","threadId":"21734","inReplyTo":"20091127095914.GA4865@sigill.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-27T10:53:42Z","receivedAt":"2009-11-27T10:53:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Nov 2009, Jeff King wrote:\n\n> On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:\n> \n> > Guess what. I have a similar problem, only it is that my \"git status\" \n> > output is _always_ too long, so I always have to page it.\n> > \n> > Once upon a time, Junio applied a patch that implied -p with status. \n> > I was overjoyed. He reverted that patch later. Yes, exactly.\n> > \n> > So I end up doing \"git config --global ps '-p status'\" on every new \n> \n> If only somebody had written a \"pager.status\" configuration variable,\n> you could use that. Oh wait. I did. And it shipped in v1.6.0.\n\nAnd it makes things inconsistent. That is why I do not use it. Do you \nwork on 10 different computers? I do. And nothing is more unnerving than \nthe same command producing something different on the different computers.\n\nSure, after a few minutes of fiddling I find out that it was my fault to \nbegin with, but dammit! if the tool makes it that hard already for an \nexpert, it is outright unusable for new users.\n\nI, for one, do not like Git's reputation, but I am tired of trying to \nfight for the users. BTW quick question: how many Git _users_ were at the \nGitTogether at MV? 0?\n\n> > account (I usually even forget to curse!), and I really cannot see why \n> > you do not do the equivalent \"git config fullgrep grep --full-tree\" in \n> > your repositories (or even the global thing).\n> >\n> > The further benefit is that we stop talking about breaking backwards \n> > compatibility, and we stop talking about making it hard for Git \n> > experts to help newbies.\n> \n> I guess you missed the part of the thread where I already discussed\n> this. It was here:\n> \n> http://article.gmane.org/gmane.comp.version-control.git/133672\n\nI only skimmed it, yes. And I did not plan to participate in this thread. \nBut it seems that my views are not represented enough, even if gitzilla \nchimed in with the very valid, under-acknowledged and over-ignored \nmessage: consistency is good. Corollary: inconsistency is bad.\n\nCiao,\nDscho\n"},{"id":"128560","messageId":"alpine.DEB.1.00.0911271155310.4521@intel-tinevez-2-302","threadId":"21734","inReplyTo":"vpq8wdsqmm4.fsf@bauges.imag.fr","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-27T10:56:58Z","receivedAt":"2009-11-27T10:56:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Nov 2009, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> > Guess what. I have a similar problem, only it is that my \"git status\" \n> > output is _always_ too long, so I always have to page it.\n> >\n> > Once upon a time, Junio applied a patch that implied -p with status. \n> > I was overjoyed. He reverted that patch later. Yes, exactly.\n> \n> In this particular example, a config variable was added (pager.status = \n> true). But one big difference is that while pager.status = true can be \n> /annoying/ for some users, it can never really harm (since the pager \n> will automatically disable itself in the cases where you'd really don't \n> want it).\n\nIt changes behavior. And worse: it changes behavior _in a different \nmanner_ in different repositories. I have too many of them to remember \nwhat I set where.\n\nSo it is harmful in a very real sense.\n\n> > So I end up doing \"git config --global ps '-p status'\" on every new \n> > account (I usually even forget to curse!), and I really cannot see why you \n> > do not do the equivalent \"git config fullgrep grep --full-tree\" in your \n> > repositories (or even the global thing).\n> \n> (I guess you meant alias.fullgrep)\n\nYou guessed right, and likewise alias.ps.\n\nCiao,\nDscho\n"},{"id":"128576","messageId":"6839293b0911270827x54947c64q5f93e37664bc20f3@mail.gmail.com","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911271144230.4521@intel-tinevez-2-302","subject":"Re: [PATCH] grep: --full-tree","fromName":"Uri Okrent","fromEmail":"uokrent@gmail.com","sentAt":"2009-11-27T16:27:03Z","receivedAt":"2009-11-27T16:27:03Z","isPatch":true,"sender":{"key":"uokrent@gmail.com","avatar":"https://gravatar.com/avatar/7788ed2d4f1bfefc11082b08b0234fd2d752113623753bda4a032a2ae9687acf?d=mp&s=160"},"body":"I've been following this thread for a long time and now I feel the\nneed to chime in...\n\nOn Fri, Nov 27, 2009 at 2:53 AM, Johannes Schindelin\n wrote:\n> And it makes things inconsistent.  That is why I do not use it.\n\nThe number one problem my users have with git is inconsistent\nbehavior, both internally to git, and externally with respect to the\nrest of the OS. But really, the issue is one of managing expectations,\nwhich is where we here tend to fall down.\n\nWhen you name the command grep, whether you like it of not,\nyou've bought into a certain set of expectations from the user\nwho has been using unix's grep since she was a baby. Saying,\n\"well, in git it works this way\", (or saying \"well in git those path\nlooking things you've been providing to commands are not really\npaths, so don't expect them to act as such\"), would make my\nusers want to vomit all over me, and then, not use git (a shame\nsince it's the best scm system around IMHO).\n\nIf we intend the behavior of the command to be materially different\nfrom the good old unix standby, then we shouldn't use the same\nname, and create the expectation that they are getting essentially\nthe same thing (git search, git pickaxe, or something carries no\nsemantic baggage---and no, I'm not suggesting we change the\nname).\n\n> I, for one, do not like Git's reputation...\n\nThere's the rub. How do we achieve consistency without breaking the\nworld? The short answer is, you really can't. As programmers we tend\nto be a very timid bunch, but sometimes (and David A. can attest to\nthis, at least at dayjob) it's better to just make a change for the better,\nand just deal with the breakages. It is possible to change behavior (and\neven break some scripts! I firmly believe it is worthwhile sacrificing\nsome scripts on the altar of consistency).\n\nThe key once again, is managing expectations. We can't go around\nchanging everything willy-nilly, and we can't be continually changing\nthings. Here is where we could take a lesson from the python\ncommunity.\n\nWhen they decided they needed to change things, they bundled a\nbunch of backwards incompatible changes together and went for it.\nYes, Python 3 will break your scripts, but the most important thing is,\neverybody knows it.\n\nA similar thing was done here with the huge warning that push spits\nout, but in the general case I would argue, that the wisest course is to\nsave backwards incompatible changes for a git 2 or something, where\nwe know we're breaking the world, and then scratch all our (well thought\nout) backwards incompatible itches at once.\n\nWhew. A bit of a rant, but there you go...\n-- \n Uri\n\nPlease consider the environment before printing this message.\nhttp://www.panda.org/how_you_can_help/\n"},{"id":"128582","messageId":"20091127180235.GA26633@coredump.intra.peff.net","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911271144230.4521@intel-tinevez-2-302","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T18:02:35Z","receivedAt":"2009-11-27T18:02:35Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 27, 2009 at 11:53:42AM +0100, Johannes Schindelin wrote:\n\n> > If only somebody had written a \"pager.status\" configuration variable,\n> > you could use that. Oh wait. I did. And it shipped in v1.6.0.\n> \n> And it makes things inconsistent. That is why I do not use it. \n\nThen you can not use this configuration variable, too. Has the existence\nof pager.status, since you do not use it, been a problem for you so far?\n\n> Do you work on 10 different computers? I do. And nothing is more\n> unnerving than the same command producing something different on the\n> different computers.\n\nYes, as a matter of fact, I do work on 10 different computers. I'm sorry\nthat you find managing your configuration so challenging. But if you\ndon't use the configuration variable, then your own personal setup is\ntotally irrelevant.\n\nIf your argument is that this lack of consistency will irritate users,\nyou need to show that:\n\n 1. There are users who switch between a large number of setups, but\n will not apply config consistently.\n\n 2. Some of these setups will be using the new config option.\n\nIf they are all controlled by a single user, how is that user any worse\noff for the config option existing? They can choose not to use it if\nthe hassle is not worth it. I do not think the existence of an option is\ngiving too much rope to these users.\n\nIf you are talking about 10 machines, all controlled by different users,\nwhose terminals you have to sit down on to help them, then yes, it will\nbe inconvenient for you. But if users are setting up configuration for\nthese machines, shouldn't _their_ convenience in using configuration\ntrump _your_ convenience for occasionally sitting down and helping them?\n\n> I, for one, do not like Git's reputation, but I am tired of trying to \n> fight for the users. BTW quick question: how many Git _users_ were at the \n> GitTogether at MV? 0?\n\nIn my opinion, you are actively fighting _against_ a user in this case.\n\nAnd the GitTogether had a \"users complain about git, and we try to\nlisten\" session. There were two google users in person, but we also went\nthrough a list of pre-made questions from other googlers. This issue\nwasn't discussed, though. Nor was the question of consistency between\nconfigurations, to my recollection. I think Shawn may have taken notes,\nand could be more specific.\n\n> > http://article.gmane.org/gmane.comp.version-control.git/133672\n> \n> I only skimmed it, yes. And I did not plan to participate in this thread. \n> But it seems that my views are not represented enough, even if gitzilla \n> chimed in with the very valid, under-acknowledged and over-ignored \n> message: consistency is good. Corollary: inconsistency is bad.\n\nThat is an over-simplification. Inconsistency between setups is bad. But\nso is inconsistency between git commands, and between git and other\ncommands. So is not supporting a user's workflow, or supporting it in a\nway that is tedious and error-prone. You have to weigh the badness of\nthose things against each other in finding a solution.\n\nBut then, that was the point I already made in the article linked above.\n\n-Peff\n"},{"id":"128587","messageId":"7vpr73n7ns.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091127095914.GA4865@sigill.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T18:29:11Z","receivedAt":"2009-11-27T18:29:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Nov 27, 2009 at 10:31:30AM +0100, Johannes Schindelin wrote:\n>\n>> Guess what. I have a similar problem, only it is that my \"git status\" \n>> output is _always_ too long, so I always have to page it.\n>> \n>> Once upon a time, Junio applied a patch that implied -p with status. I \n>> was overjoyed. He reverted that patch later. Yes, exactly.\n\nIt would have been more fair to me if Dscho said \"He had to revert\", to\nhint that it was not due to me changing the preference left and right on a\nwhim.\n\n>> So I end up doing \"git config --global ps '-p status'\" on every new \n>\n> If only somebody had written a \"pager.status\" configuration variable,\n> you could use that. Oh wait. I did. And it shipped in v1.6.0.\n\nNice try but, \"grep\" and \"status\" are apples and oranges comparision.\n\nA \"status\" command that pages or does not page the output only when\nspitting out to a terminal won't hurt somebody who helps another with the\nconfiguration set differently, as much as a \"grep\" that shows or not shows\nmatches from other parts of the tree would, and when used by a script to\nmake a decision based on the output, the caller has to capture the output\nfirst, and unless the caller drives \"status\" via pty, e.g. using \"expect\",\npaging behaviour will be disabled no matter what the configuration setting\nis.\n\nSo neither \"it would hurt people who help others\" nor \"it would hurt\nscripts\" would apply to \"status\". But both would apply to \"grep\".\n\n>> The further benefit is that we stop talking about breaking backwards \n>> compatibility, and we stop talking about making it hard for Git experts to \n>> help newbies.\n>\n> I guess you missed the part of the thread where I already discussed\n> this. It was here:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/133672\n\nThis was a very good summary, and was one of the reasons that made me\nreconsider placing too much weight on \"it would hurt people who help\nothers\" (but not on \"it would hurt scripts\").\n"},{"id":"128588","messageId":"7vk4xbn7nl.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"6839293b0911270827x54947c64q5f93e37664bc20f3@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T18:29:18Z","receivedAt":"2009-11-27T18:29:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Uri Okrent writes:\n\n> The key once again, is managing expectations. We can't go around\n> changing everything willy-nilly, and we can't be continually changing\n> things. Here is where we could take a lesson from the python\n> community.\n>\n> When they decided they needed to change things, they bundled a\n> bunch of backwards incompatible changes together and went for it.\n> Yes, Python 3 will break your scripts, but the most important thing is,\n> everybody knows it.\n>\n> A similar thing was done here with the huge warning that push spits\n> out, but in the general case I would argue, that the wisest course is to\n> save backwards incompatible changes for a git 2 or something, where\n> we know we're breaking the world, and then scratch all our (well thought\n> out) backwards incompatible itches at once.\n\nYou preach to the choir.\n\nThat is exactly how we work and what people have been working hard for\n1.7.0. Check the planned changes listed in the recent (and not so recent)\n\"What's cooking\" summary reports.\n\nChanging \"grep\" is too late for 1.7.0, but we are trying to find an easy\nmigration path like you mentioned in your message and that is exactly what\nthis thread is about.\n"},{"id":"128592","messageId":"4B101ED1.9000607@gmail.com","threadId":"21734","inReplyTo":"7vk4xbn7nl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Uri Okrent","fromEmail":"uokrent@gmail.com","sentAt":"2009-11-27T18:47:45Z","receivedAt":"2009-11-27T18:47:45Z","isPatch":true,"sender":{"key":"uokrent@gmail.com","avatar":"https://gravatar.com/avatar/7788ed2d4f1bfefc11082b08b0234fd2d752113623753bda4a032a2ae9687acf?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> You preach to the choir.\n> \n> That is exactly how we work and what people have been working hard for\n> 1.7.0. Check the planned changes listed in the recent (and not so recent)\n> \"What's cooking\" summary reports.\n\nYes, I guess my only point here was that maybe even 1.7 is not enough of\na \"Big Deal\" (in the eyes of the public) to warrant breaking scripts. A\n2.0 version would be a more visible way to say \"Hey test your scripts\nbefore upgrading\". Adopting a strategy like that would mean making\nbackwards incompatible changes a lot let frequently, but when we do we\ngo for broke.\n\n> Changing \"grep\" is too late for 1.7.0, but we are trying to find an easy\n> migration path like you mentioned in your message and that is exactly what\n> this thread is about.\n\nI wasn't actually suggesting we change grep for 1.7. As a matter of\nfact, my personal opinion (which I probably neglected to mention) is\nthat grep default behavior should stay the same since it is semantically\ncloser to unix (or gnu) grep.\n\n-- \n Uri\n\nPlease consider the environment before printing this message.\nhttp://www.panda.org/how_you_can_help/\n"},{"id":"128598","messageId":"alpine.DEB.1.00.0911272102430.4521@intel-tinevez-2-302","threadId":"21734","inReplyTo":"20091127180235.GA26633@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-27T20:07:51Z","receivedAt":"2009-11-27T20:07:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Nov 2009, Jeff King wrote:\n\n> On Fri, Nov 27, 2009 at 11:53:42AM +0100, Johannes Schindelin wrote:\n> \n> > > If only somebody had written a \"pager.status\" configuration variable,\n> > > you could use that. Oh wait. I did. And it shipped in v1.6.0.\n> > \n> > And it makes things inconsistent. That is why I do not use it. \n> \n> Then you can not use this configuration variable, too. Has the existence\n> of pager.status, since you do not use it, been a problem for you so far?\n\nNo, since none of the people I helped use it.\n\n> > Do you work on 10 different computers? I do. And nothing is more \n> > unnerving than the same command producing something different on the \n> > different computers.\n> \n> Yes, as a matter of fact, I do work on 10 different computers. I'm sorry \n> that you find managing your configuration so challenging. But if you \n> don't use the configuration variable, then your own personal setup is \n> totally irrelevant.\n\nAs I just demonstrated, this is a false statement.\n\n> If your argument is that this lack of consistency will irritate users,\n> you need to show that:\n> \n> 1. There are users who switch between a large number of setups, but\n> will not apply config consistently.\n\nThis is a strawman, and you should be ashamed to put it here. Just \nbecause nobody does what you actively encourage does not mean that the \nencouraged procedure is good, or for that matter, helps anybody but you.\n\nJust think about it. If you plan to change the side cars are supposed to \ndrive on, it is not enough to have a nice cozy committee deciding on it in \nsome little room somewhere in Wyoming. Especially not if they decide that \nyou can drive on the other side if you put a sticker \"I am a right-wing \ndriver\" on your car.\n\nIt is inconsistent, and it is violating the law of the least surprise.\n\n> And the GitTogether had a \"users complain about git, and we try to\n> listen\" session.\n\nOh, that makes me so happy. Soooo happy. So it was an \nivory tower meeting, once again?\n\nCiao,\nDscho\n"},{"id":"128603","messageId":"20091127205004.GA26921@coredump.intra.peff.net","threadId":"21734","inReplyTo":"7vpr73n7ns.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T20:50:04Z","receivedAt":"2009-11-27T20:50:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 27, 2009 at 10:29:11AM -0800, Junio C Hamano wrote:\n\n> > If only somebody had written a \"pager.status\" configuration variable,\n> > you could use that. Oh wait. I did. And it shipped in v1.6.0.\n> \n> Nice try but, \"grep\" and \"status\" are apples and oranges comparision.\n\nYes, I think you are right that the existence of pager.* does not\nnecessarily imply that there should be a config option for grep. But\nthat makes his example even more irrelevant: he is advocating that I use\na solution in this instance because he uses it in another instance, when\nthat solution is not even necessary in the other instance (and as I have\nhopefully already made clear, is in my opinion inferior).\n\nIt is probably better to stay on the topic of the grep option, though.\n\n-Peff\n"},{"id":"128604","messageId":"20091127205305.GB26921@coredump.intra.peff.net","threadId":"21734","inReplyTo":"4B101ED1.9000607@gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T20:53:05Z","receivedAt":"2009-11-27T20:53:05Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 27, 2009 at 10:47:45AM -0800, Uri Okrent wrote:\n\n> >Changing \"grep\" is too late for 1.7.0, but we are trying to find an easy\n> >migration path like you mentioned in your message and that is exactly what\n> >this thread is about.\n> \n> I wasn't actually suggesting we change grep for 1.7. As a matter of\n> fact, my personal opinion (which I probably neglected to mention) is\n> that grep default behavior should stay the same since it is semantically\n> closer to unix (or gnu) grep.\n\nKeeping consistency with non-git grep has been mentioned a few times in\nthis thread. I really don't understand how default file selection is\nsupposed to maintain consistency with non-git grep. Regular grep\ndefaults to stdin if no paths are given. That mode doesn't make any\nsense for git grep.\n\nSo of the two options (grepping the list of files from the full tree, or\nthe list of files rooted at the current directory), how is one closer to\nnon-git grep than the other?\n\n-Peff\n"},{"id":"128606","messageId":"20091127210530.GC26921@coredump.intra.peff.net","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911272102430.4521@intel-tinevez-2-302","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T21:05:30Z","receivedAt":"2009-11-27T21:05:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 27, 2009 at 09:07:51PM +0100, Johannes Schindelin wrote:\n\n> > Yes, as a matter of fact, I do work on 10 different computers. I'm sorry \n> > that you find managing your configuration so challenging. But if you \n> > don't use the configuration variable, then your own personal setup is \n> > totally irrelevant.\n> \n> As I just demonstrated, this is a false statement.\n\nI must have missed where you demonstrated it.\n\n> > If your argument is that this lack of consistency will irritate users,\n> > you need to show that:\n> > \n> > 1. There are users who switch between a large number of setups, but\n> > will not apply config consistently.\n> \n> This is a strawman, and you should be ashamed to put it here. Just \n\nHow is this a strawman? A strawman would be me overstating an\nexaggerated position by you and then arguing against it. All I have\nclaimed is that it is not sufficient for _you_ to be personally annoyed\nby this existence of this option. You need to argue that there is a\nsignificant group of people in the same situation who will be ignored.\n\nOr have I mis-spoken in summarizing your claim that a \"lack of\nconsistency will irritate users\". Is that not your point?\n\n> Just think about it. If you plan to change the side cars are supposed to \n> drive on, it is not enough to have a nice cozy committee deciding on it in \n> some little room somewhere in Wyoming. Especially not if they decide that \n> you can drive on the other side if you put a sticker \"I am a right-wing \n> driver\" on your car.\n\nWhen the number of \"git grep\" crash fatalities rises above zero, maybe\nthis line of reasoning will be relevant.\n\nI am talking about making software configurable so that people, in their\nown private setups, can make the software work as they see fit. Yes, it\nis possible for that setup to be visible to other people in some\nsituations. But I am arguing that we need to weigh the (in my opinion\nsubstantial) inconvenience to users in their everyday work compared to\nthe inconvenience of one user sitting at another user's terminal (or\ncutting and pasting commands, or running a script).\n\n> > And the GitTogether had a \"users complain about git, and we try to\n> > listen\" session.\n> \n> Oh, that makes me so happy. Soooo happy. So it was an \n> ivory tower meeting, once again?\n\nI don't know what to say. You complain and complain about how git is not\nbeing responsive to users. Shawn organizes a session where people at\nGoogle who are using git every day can try to make their complaints in\nan organized forum where a bunch of developers will listen and talk\nabout ways we can address those complaints. And now you are mad about\nthat?\n\nIf you think we need a git conference where lots of users show up, I\nthink that's a great idea. But until you provide some suggestions about\nhow to organize such a thing, I don't see how you are helping anything.\n\n-Peff\n"},{"id":"128676","messageId":"alpine.DEB.1.00.0911291118280.4985@pacific.mpi-cbg.de","threadId":"21734","inReplyTo":"20091127205004.GA26921@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-29T10:21:06Z","receivedAt":"2009-11-29T10:21:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Nov 2009, Jeff King wrote:\n\n> On Fri, Nov 27, 2009 at 10:29:11AM -0800, Junio C Hamano wrote:\n> \n> > > If only somebody had written a \"pager.status\" configuration variable,\n> > > you could use that. Oh wait. I did. And it shipped in v1.6.0.\n> > \n> > Nice try but, \"grep\" and \"status\" are apples and oranges comparision.\n> \n> Yes, I think you are right that the existence of pager.* does not\n> necessarily imply that there should be a config option for grep. But\n> that makes his example even more irrelevant: he is advocating that I use\n> a solution in this instance because he uses it in another instance, when\n> that solution is not even necessary in the other instance (and as I have\n> hopefully already made clear, is in my opinion inferior).\n\nSorry, no, you got it all wrong.\n\nMy point was that your config option introduced something _BAD_. And my \npoint was that now, as a consequence of having managed to put it into Git, \nyou want more of such bad stuff.\n\nYou continue to ignore that inconsistency -- even if it is introduced with \nthe best of all intentions -- is bad, bad, bad.\n\nBut I guess that I continue to get ignored,\nDscho\n"},{"id":"128677","messageId":"alpine.DEB.1.00.0911291121300.4985@pacific.mpi-cbg.de","threadId":"21734","inReplyTo":"20091127210530.GC26921@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-29T10:28:27Z","receivedAt":"2009-11-29T10:28:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 27 Nov 2009, Jeff King wrote:\n\n> On Fri, Nov 27, 2009 at 09:07:51PM +0100, Johannes Schindelin wrote:\n> \n> > > Yes, as a matter of fact, I do work on 10 different computers. I'm sorry \n> > > that you find managing your configuration so challenging. But if you \n> > > don't use the configuration variable, then your own personal setup is \n> > > totally irrelevant.\n> > \n> > As I just demonstrated, this is a false statement.\n> \n> I must have missed where you demonstrated it.\n\nUsually, my mails are minimal, and I do not write as many mails as I \nused to anymore, so it is hard to miss what I am saying.\n\nFor your benefit: both Junio and me talked about experts helping users. \nEven if I do not use the config options, I am affected. And it does hurt.\n\n> > > If your argument is that this lack of consistency will irritate users,\n> > > you need to show that:\n> > > \n> > > 1. There are users who switch between a large number of setups, but\n> > > will not apply config consistently.\n> > \n> > This is a strawman, and you should be ashamed to put it here. Just \n> \n> How is this a strawman?\n\nYou are comparing config settings which must be different, because they \naffect _what_ project you are working with, with config settings that \naffect _how_ you can work with them.\n\n> When the number of \"git grep\" crash fatalities rises above zero, maybe \n> this line of reasoning will be relevant.\n\nSure. Let's wait for the first crash fatality, and only react then. No \nneed to think ahead.\n\nThat's it. I don't think that I want to participate in this kind of \ndiscussion anymore,\nDscho\n"},{"id":"128680","messageId":"94a0d4530911290338h459dd5a2p4752f7d58c455964@mail.gmail.com","threadId":"21734","inReplyTo":"20091125232210.GA15538@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-11-29T11:38:23Z","receivedAt":"2009-11-29T11:38:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 26, 2009 at 1:22 AM, Jeff King wrote:\n> Probably we would want something flexible, but with sane defaults. Like\n> an environment variable to ignore all (or most) config options, but then\n> the ability to opt into specific ones. Something like:\n>\n>  GIT_PLUMBING=1; export GIT_PLUMBING\n>  git log ;# does not respect any non-plumbing config\n>  git --respect='log.showroot' ;# respect just the one variable\n>  git --respect='color.*' log ;# you get all color\n>\n> But there are two big obstacles (besides the obvious issue that\n> introducing this in itself needs a gentle transition plan):\n>\n>  1. We need to annotate every config option with whether it is\n>     potentially problematic. For example, core.filemode should probably\n>     be respected no matter what (but I'm not sure if it is simply true\n>     for core.*).\n>\n>  2. Script writers need to actually use the system, which is somewhat\n>     more verbose and annoying than what they have to do now. But at\n>     least it defaults to safety when they are lazy, and then they can\n>     re-add options. Of course, they are stuck on an upgrade treadmill\n>     of analyzing and approving each new option that appears in git.\n\n+1 on this.\n\nThis would make it easier to add options in the future that would be\npotentially dangerous to scripts otherwise. But more than\n\"non-plumbing\" I would rather define these variables as *preferences*;\nthings that are not essential to the proper functioning of git\ncommands, and would vary from user to user.\n\n-- \nFelipe Contreras\n"},{"id":"128681","messageId":"94a0d4530911290348mf3b713aq15fe45ce92743b9d@mail.gmail.com","threadId":"21734","inReplyTo":"7vk4xbn7nl.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] grep: --full-tree","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-11-29T11:48:55Z","receivedAt":"2009-11-29T11:48:55Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 27, 2009 at 8:29 PM, Junio C Hamano wrote:\n> That is exactly how we work and what people have been working hard for\n> 1.7.0.  Check the planned changes listed in the recent (and not so recent)\n> \"What's cooking\" summary reports.\n>\n> Changing \"grep\" is too late for 1.7.0, but we are trying to find an easy\n> migration path like you mentioned in your message and that is exactly what\n> this thread is about.\n\nHow about this. For now, make --full-tree available, and that's it.\nThen, on 1.8.0, add the configuration option, and if there's consensus\nmake it default (-1 from me).\n\nHowever, in order to ease the transition I think Jeff's GIT_PLUMBING\n(I would call it GIT_SCRIPTING) should be introduced on 1.7.0 so\npeople can start exporting it in their scripts. That way people don't\nhave to worry about adding --(no-)full-tree on their scripts (nor any\nother argument that depends on configurations) and when 1.8.0 comes,\nthere's no script breakage.\n\n-- \nFelipe Contreras\n"},{"id":"128682","messageId":"94a0d4530911290413vbd71849u62ef01ed76bad4c0@mail.gmail.com","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911272102430.4521@intel-tinevez-2-302","subject":"Re: [PATCH] grep: --full-tree","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-11-29T12:13:17Z","receivedAt":"2009-11-29T12:13:17Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 27, 2009 at 10:07 PM, Johannes Schindelin\n wrote:\n> On Fri, 27 Nov 2009, Jeff King wrote:\n>> Yes, as a matter of fact, I do work on 10 different computers. I'm sorry\n>> that you find managing your configuration so challenging. But if you\n>> don't use the configuration variable, then your own personal setup is\n>> totally irrelevant.\n>\n> As I just demonstrated, this is a false statement.\n\nYes, defaults are important in UI.\n\n>> If your argument is that this lack of consistency will irritate users,\n>> you need to show that:\n>>\n>>   1. There are users who switch between a large number of setups, but\n>>      will not apply config consistently.\n>\n> This is a strawman, and you should be ashamed to put it here.  Just\n> because nobody does what you actively encourage does not mean that the\n> encouraged procedure is good, or for that matter, helps anybody but you.\n\nNot to mention that it's completely irrelevant. The fact that all\nusers apply their configurations consistently through their setups, or\nnot, doesn't make a default preference better or worst.\n\nIf the argument is that default preferences are not relevant enough,\nthen step aside and let the people that care about default preferences\nto discuss.\n\n>> And the GitTogether had a \"users complain about git, and we try to\n>> listen\" session.\n>\n> Oh, that makes me so happy.  Soooo happy.  So it was an\n> ivory tower meeting, once again?\n\nThis is very typical on many open source projects. I think the\nbenevolent dictator model works pretty good on low-level stuff, but on\nUI I think a democratic model works better.\n\nI've been thinking on setting up a pseudo-project on SourceForge and\nsetup an IdeaTorrent, that way users can generate and organize ideas\nso that developers can have meaningful conversations with users:\nhttp://brainstorm.ubuntu.com/\n\nWhat do you think?\n\n-- \nFelipe Contreras\n"},{"id":"128698","messageId":"20091129182402.GA21520@sigill.intra.peff.net","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911291118280.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-29T18:24:03Z","receivedAt":"2009-11-29T18:24:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 29, 2009 at 11:21:06AM +0100, Johannes Schindelin wrote:\n\n> You continue to ignore that inconsistency -- even if it is introduced with \n> the best of all intentions -- is bad, bad, bad.\n> \n> But I guess that I continue to get ignored,\n\nSpeaking of ignoring, you have never once responded to my repeated point\nthat I agree that inconsistency is bad, but it is about weighing that\nbad against other bad things.\n\n-Peff\n"},{"id":"128699","messageId":"20091129183217.GB21520@sigill.intra.peff.net","threadId":"21734","inReplyTo":"alpine.DEB.1.00.0911291121300.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH] grep: --full-tree","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-29T18:32:17Z","receivedAt":"2009-11-29T18:32:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:\n\n> > > > Yes, as a matter of fact, I do work on 10 different computers. I'm sorry \n> > > > that you find managing your configuration so challenging. But if you \n> > > > don't use the configuration variable, then your own personal setup is \n> > > > totally irrelevant.\n> > > \n> > > As I just demonstrated, this is a false statement.\n> > \n> > I must have missed where you demonstrated it.\n> \n> Usually, my mails are minimal, and I do not write as many mails as I \n> used to anymore, so it is hard to miss what I am saying.\n> \n> For your benefit: both Junio and me talked about experts helping users. \n> Even if I do not use the config options, I am affected. And it does hurt.\n\nA point which I adressed in my numbered point (2) in the mail you are\nquoting above. But you didn't bother to quote that part.\n\n> > When the number of \"git grep\" crash fatalities rises above zero, maybe \n> > this line of reasoning will be relevant.\n> \n> Sure. Let's wait for the first crash fatality, and only react then. No \n> need to think ahead.\n\nYou missed my point. My point is that your analogy had many\ncharacteristics that do not apply to this situation. You are comparing a\nsituation where somebody's preference (to drive on the left side or the\nright side) is weighed against a system where everyone needs to follow\nthe same rule, or people will die in large numbers. The actual situation\nat hand is a git grep configuration variable. I am weighing the\npreference of people who use git every day and want it to work in a\ncertain way against the possibility that somebody helping them will be\nslightly inconvenienced or surprised. Something that will happen much\nless frequently than the person actually _using_ git, and something\nwhich has much smaller negative consequences than people dying.\n\n> That's it. I don't think that I want to participate in this kind of \n> discussion anymore,\n\nFine. I have made my point over and over, and not once have you\nresponded to it directly, so I also feel this is going nowhere.\n\n-Peff\n"},{"id":"128702","messageId":"4B12CF63.3040400@gmail.com","threadId":"21734","inReplyTo":"94a0d4530911290338h459dd5a2p4752f7d58c455964@mail.gmail.com","subject":"Re: [PATCH] grep: --full-tree","fromName":"Uri Okrent","fromEmail":"uokrent@gmail.com","sentAt":"2009-11-29T19:45:39Z","receivedAt":"2009-11-29T19:45:39Z","isPatch":true,"sender":{"key":"uokrent@gmail.com","avatar":"https://gravatar.com/avatar/7788ed2d4f1bfefc11082b08b0234fd2d752113623753bda4a032a2ae9687acf?d=mp&s=160"},"body":"Felipe Contreras wrote:\n> On Thu, Nov 26, 2009 at 1:22 AM, Jeff King wrote:\n>> Probably we would want something flexible, but with sane defaults. Like\n>> an environment variable to ignore all (or most) config options, but then\n>> the ability to opt into specific ones. Something like:\n>>\n>> GIT_PLUMBING=1; export GIT_PLUMBING\n>> git log ;# does not respect any non-plumbing config\n>> git --respect='log.showroot' ;# respect just the one variable\n>> git --respect='color.*' log ;# you get all color\n>>\n>> But there are two big obstacles (besides the obvious issue that\n>> introducing this in itself needs a gentle transition plan):\n>>\n>> 1. We need to annotate every config option with whether it is\n>> potentially problematic. For example, core.filemode should probably\n>> be respected no matter what (but I'm not sure if it is simply true\n>> for core.*).\n>>\n>> 2. Script writers need to actually use the system, which is somewhat\n>> more verbose and annoying than what they have to do now. But at\n>> least it defaults to safety when they are lazy, and then they can\n>> re-add options. Of course, they are stuck on an upgrade treadmill\n>> of analyzing and approving each new option that appears in git.\n> \n> +1 on this.\n> \n> This would make it easier to add options in the future that would be\n> potentially dangerous to scripts otherwise. But more than\n> \"non-plumbing\" I would rather define these variables as *preferences*;\n> things that are not essential to the proper functioning of git\n> commands, and would vary from user to user.\n> \n\nSounds like a good idea to me, speaking as someone who has git support\nscripts. Dealing with configuration soup in every script would be very\nbad.\n\nThe same type of insulation though could probably be achieved by not\nadding configuration options that alter the behavior of commands,\nand instead have user's rely on aliases for that purpose. (The cat's\nprobably already out of the bag WRT to configuration though).\n\n-- \n Uri\n\nPlease consider the environment before printing this message.\nhttp://www.panda.org/how_you_can_help/\n"},{"id":"128703","messageId":"7v3a3x9kml.fsf@alter.siamese.dyndns.org","threadId":"21734","inReplyTo":"20091129183217.GB21520@sigill.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-29T19:49:38Z","receivedAt":"2009-11-29T19:49:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Nov 29, 2009 at 11:28:27AM +0100, Johannes Schindelin wrote:\n> ...\n>> > When the number of \"git grep\" crash fatalities rises above zero, maybe \n>> > this line of reasoning will be relevant.\n>> \n>> Sure. Let's wait for the first crash fatality, and only react then. No \n>> need to think ahead.\n>\n> ... The actual situation\n> at hand is a git grep configuration variable. I am weighing the\n> preference of people who use git every day and want it to work in a\n> certain way against the possibility that somebody helping them will be\n> slightly inconvenienced or surprised.\n\nWhile my position is *not* \"hurting people who help is too grave and we\nshouldn't even weigh other upsides against it---bad is bad is bad, and it\nis absolutely bad\" (which is what I think Dscho is saying), I think\n\"slightly inconvenienced or surprised\" is trying to make it sound a lot\nlighter than it is.\n\nImagine you are helping somebody to track down a bug in a project whose\nsource happens to be under git. You two scratch your heads together, and\nyou try to find if the function you are fixing have other call sites, and\nyou run \"git grep\" to find them. You think you covered the whole tree,\nidentified all the callsites and made sure that the updated behaviour of\nthe function with your fix is consistent with all of them. But it turns\nout that you didn't check the whole tree, due to user's configuration, and\nyou didn't notice.\n\nYou can easily waste 30 minutes of two people until you realize what\nhappened. Because the whole point of your grep.fulltree configuration is\nthat you can set it once and forget about it, even after you noticed that\nyour grep didn't look in the whole tree as you expected, the configuration\nvariable is not the first thing that will come to your mind. You will\nwaste more minutes wondering why grep is not working as you expect, until\nyou finally come up with a suggestion to set the configuration to make\ngrep look in the full tree by default in her repository.\n\nPut it another way, your \"I can set it and forget about it\" may be a way\nto solve \"differentiating two things is a mental burden and I do not want\nto think about it\". But I do not think the \"mental burden\" problem is\nnecessarily what we want to solve. The \"set and forget\" will bring\nconfusion.\n\nThe best solution to the \"mental burden\" problem may not even be \"I can\nset it and forget about it\". An obvious solution to that problem, that is\nfar easier to explain, is not to have two things to begin with, and that is\nwhat we do: \"If you want to grep in the whole tree, you go to the top and\nrun grep there.\" Of course, its downside is that it is often cumbersome\nto \"got to the top\" when you are somewhere deep.\n\nThat is why I think it would be a lot better solution to spend our efforts\nmaking sure that both semantics can be called for from the command line in\na concise and clear way. IOW, the problem I see worth solving first is\nnot the \"mental burden\" problem, but is \"differentiating two things is\nnecessary, but it is cumbersome to say which one I want.\"\n\nYou probably can add both configuration and concise command line syntax,\nbut \"solving\" the \"mental burden\" problem will make you forget about the\nneed to use --full-tree option (or its quivalent that will happen in the\nsolution of the \"cumbersome to say which one I want\" problem). On the\nother hand, not \"solving\" the \"mental burden\" problem will hopefully train\nyour brain and your fingers to always be aware of and to say which one you\nwant, to the point that you do not even have to think.\n\nFor that to happen, \"cumbersome to say which\" problem must be solved\nnicely, of course.\n\n> ... Something that will happen much\n> less frequently than the person actually _using_ git, and something\n> which has much smaller negative consequences than people dying.\n\nIt is of course not _fatal_, but there are not many things that are fatal.\nSaying \"that is not fatal so it is Ok\" is not particularly a good way to\nweigh downsides against upsides.\n"},{"id":"128704","messageId":"4B12D09A.3080408@gmail.com","threadId":"21734","inReplyTo":"20091127205305.GB26921@coredump.intra.peff.net","subject":"Re: [PATCH] grep: --full-tree","fromName":"Uri Okrent","fromEmail":"uokrent@gmail.com","sentAt":"2009-11-29T19:50:50Z","receivedAt":"2009-11-29T19:50:50Z","isPatch":true,"sender":{"key":"uokrent@gmail.com","avatar":"https://gravatar.com/avatar/7788ed2d4f1bfefc11082b08b0234fd2d752113623753bda4a032a2ae9687acf?d=mp&s=160"},"body":"Jeff King wrote:\n> On Fri, Nov 27, 2009 at 10:47:45AM -0800, Uri Okrent wrote:\n>> As a matter of\n>> fact, my personal opinion (which I probably neglected to mention) is\n>> that grep default behavior should stay the same since it is semantically\n>> closer to unix (or gnu) grep.\n> \n> Keeping consistency with non-git grep has been mentioned a few times in\n> this thread. I really don't understand how default file selection is\n> supposed to maintain consistency with non-git grep. Regular grep\n> defaults to stdin if no paths are given. That mode doesn't make any\n> sense for git grep.\n> \n> So of the two options (grepping the list of files from the full tree, or\n> the list of files rooted at the current directory), how is one closer to\n> non-git grep than the other?\n> \n> -Peff\n\nI guess you're right, in that neither is exactly the same as non-git,\nand so it's impossible to objectively quantify how one is \"closer\". My\ngeneral feeling though is that grep rooted at the current directory is\nmore similar because grep -r does exist and is common enough that the\nlayman isn't too surprised at git's default behavior. Git grep with\n--full-tree though, has no analogue in non-git grep.\n\n-- \n Uri\n\nPlease consider the environment before printing this message.\nhttp://www.panda.org/how_you_can_help/\n"}]}