Stefan Beller <sbeller@xxxxxxxxxx> writes: > The plan is to hook the ls-files machinery into > git-grep as the way of obtaining files to grep for a pattern. That does not make much sense to me for exactly the same reason why the "grab the list of paths and run 'git add' on them" example in the message you are responding to does not make sense. The use of the thread-pool would still need to honor the submodule boundary so that one thread may be assigned files in the top-level superproject while another may be assigned files in lib/ submodule repository, and the latter would be doing a rough equivalent of "git -C lib grep" perhaps with a new option "--output-path-prefix=lib/" that makes any and all paths that are reported from the command prefixed with the specified string, so the result of its grepping in Makefile may be reported as findings in lib/Makefile. For that, it is not sufficient for the enumeration of paths done in the top-level to just list lib/Makefile and lib/hello.py along with Makefile and main.py, is it? You would somehow need to have a way to tell that 'lib/' and everything in there is inside a separate repository. Without knowing that "lib/" is its own repository, you would not even know which files under "lib/" hierarchy in the filesystem are actually tracked files, which you would learn only by reading lib/.git/index, or what textconv filtering needs to be done on them, which you would learn only by reading lib/.gitattributes and/or lib/.git/config. So a "ls-files" that is done internally in the end-user facing "git grep --recurse-submodules" needs to be run _without_ recursing itself at least once to learn "lib/" is a submodule. A flat "here are everything we have" does not sound like a good building block.