git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Ed Avis <ed.avis@qmaw.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: RE: Feature request: 'git grep' over multiple working trees
Date: Wed, 25 Mar 2020 08:04:33 +0000	[thread overview]
Message-ID: <MN2PR11MB3663199126786BCC0722593C9DCE0@MN2PR11MB3663.namprd11.prod.outlook.com> (raw)
In-Reply-To: <xmqq369x38c6.fsf@gitster.c.googlers.com>

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 :-)

The 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. 

I 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().

I 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. 

I 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.


      reply	other threads:[~2020-03-25  8:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24  7:49 Feature request: 'git grep' over multiple working trees Ed Avis
2020-03-24 18:40 ` Junio C Hamano
2020-03-25  8:04   ` Ed Avis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR11MB3663199126786BCC0722593C9DCE0@MN2PR11MB3663.namprd11.prod.outlook.com \
    --to=ed.avis@qmaw.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).