{"thread":{"id":"53080","subject":"Feature request: 'git grep' over multiple working trees","startedAt":"2020-03-24T07:59:00Z","lastAt":"2020-03-25T08:14:22Z","messageCount":3,"participants":["Ed Avis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"393867","messageId":"MN2PR11MB3663C042590097D7A7F4B2409DF10@MN2PR11MB3663.namprd11.prod.outlook.com","threadId":"53080","inReplyTo":null,"subject":"Feature request: 'git grep' over multiple working trees","fromName":"Ed Avis","fromEmail":"ed.avis@qmaw.com","sentAt":"2020-03-24T07:49:13Z","receivedAt":"2020-03-24T07:59:00Z","isPatch":false,"sender":{"key":"ed.avis@qmaw.com","avatar":null},"body":"If the current directory contains several git working trees (each in its own subdirectory) then 'git grep' should search all of them.  It would be roughly equivalent to\n\n% for i in * ; do (cd $i ; git grep whatever); done\n\nexcept that the filenames listed would have the full path.\n\nAs you see it's fairly simple to script up, and there are tools to do it (one called 'multi'), but having it built in to 'git grep' would be handy.\nIf the current directory doesn't contain any git working trees, then 'git grep' can die as it does now.  If there are some working trees and some random other stuff, it can warn and skip the other stuff.\n\nPlease ignore confidentiality stuff after this point.\n"},{"id":"393884","messageId":"xmqq369x38c6.fsf@gitster.c.googlers.com","threadId":"53080","inReplyTo":"MN2PR11MB3663C042590097D7A7F4B2409DF10@MN2PR11MB3663.namprd11.prod.outlook.com","subject":"Re: Feature request: 'git grep' over multiple working trees","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-03-24T18:40:09Z","receivedAt":"2020-03-24T18:40:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ed Avis <ed.avis@qmaw.com> writes:\n\n> If the current directory contains several git working trees (each\n> in its own subdirectory) then 'git grep' should search all of\n> them.  It would be roughly equivalent to\n>\n> % for i in * ; do (cd $i ; git grep whatever); done\n>\n> except that the filenames listed would have the full path.\n\nI am not sure where that \"should search\" comes from.\n\nIn my $HOME/w directory, I have working trees of various\nrepositories, belonging to different and unrelated projects.\nShould \"git grep foo\" in there search in everywhre?\n\nAre you looking for \"grep -r --exclude=.git\" (not a git command at\nall)?\n\nIn other words, surely anybody can wish anything nonsensical, but I\ndo not quite see the point for adding such a mode to \"Git\".\n\nIt sounds like saying 'git grep' \"should\" search all of them if the\ncurrent directly is a git repository with several git commits, which\nwould be roughly equivalent to\n\n    git rev-list --all |\n    while read rev\n    do\n\tgit grep -e pattern... $rev\n    done\n\nSimilarly, you could say that 'git grep' \"should\" search all of them\nif the current directory is a git repository with several branches,\nwhich would be roughly equivalent to\n\n    git for-each-ref --format='%(objectname)' refs/heads/ |\n    while read rev\n    do\n\tgit grep -e pattern... $rev\n    done\n\nNeither of the above smell like a reasonable use of \"should\", at\nleast to me, and yours does not, either.\n\nWhat is the real use case, if any, of what you are proposing?\n"},{"id":"393950","messageId":"MN2PR11MB3663199126786BCC0722593C9DCE0@MN2PR11MB3663.namprd11.prod.outlook.com","threadId":"53080","inReplyTo":"xmqq369x38c6.fsf@gitster.c.googlers.com","subject":"RE: Feature request: 'git grep' over multiple working trees","fromName":"Ed Avis","fromEmail":"ed.avis@qmaw.com","sentAt":"2020-03-25T08:04:33Z","receivedAt":"2020-03-25T08:14:22Z","isPatch":false,"sender":{"key":"ed.avis@qmaw.com","avatar":null},"body":"Thanks for your reply. Please interpret 'should' in the context of this being a feature request. If you reject the request then no, it should not :-)\n\nThe use case is just as you describe: having several different repositories checked out under a common root, and wanting to search all of them, while keeping the speed and other advantages of git grep. \n\nI do this multi-repos search all the time. In a pure software development context it may not make much sense. If projects are so tightly coupled that you commonly search all of them, they would be in one repository. But for in-house code in a more 'dev ops' setup it's invaluable. What code references this database table? User fred has left the company, which config files still grant him permissions? Does any other group call the Pogg() function in our in-house library? Even with a single development team you are likely to have more than one repository to search; in a larger organization you'll have other teams with their own repos which nonetheless you have to grep before you can consider changing that Pogg().\n\nI think I'm not the only one with this use case, judging by questions on q&a sites. To me it seems like a natural (though limited) extension of the existing recursive search. It doesn't change any existing behaviour or break any scripts, since it concerns a case where the current behaviour is to give an error. \n\nI appreciate one can get bogged down in questions of what happens if the working trees are two levels deep, or there is a mixture of working trees and other stuff. I have tried to keep the scope fairly narrow by stipulating a single directory which contains git trees under its top level. I believe this is a fairly common case.\n\n"}]}