Hi, On Wed, Sep 14, 2016 at 04:57:53PM -0700, Brandon Williams wrote: > --- > I've been trying to think through how we could potentially add pathspec support > for --recurse-submodule options (for builtins like ls-files or grep down the > line). This is something that could be useful if the user supply's a pathspec > that could match to a file in a submodule. We could match the submodule to the > pathspec and then fork the process to recursively run the command on the > submodule which can be passed a modified pathspec. > > For example with a pathspec 'sub/dir/a', where sub is a submodule in the root > directory of the supermodule's repo, we could match 'sub' to that spec and then > recursively call the git command with a pathspec of 'dir/a'. The child process > would then have the responsibility of matching 'dir/a' to files in its repo. > > Does this seem like a reasonable feature to add? And if so are how is my > initial approach at solving the problem? The problem when you do that is that the child is not aware that it is actually run as a submodule process. E.g. git grep --recurse-submodules foobar -- sub/dir/a would report back matches in 'dir/a' instead of 'sub/dir/a'. From the users perspective this will be confusing since she started the grep in the superproject. So what I would suggest is that we make the childs aware of the fact that they are called from a superproject by passing a prefix when calling it. E.g. like this git grep --submodule-prefix=sub foobar -- sub/dir/a Whether we pass the full or stripped path is now a matter of taste or ease of implementation, since we could either preprend or strip it in the child. But the important difference is that we have information about the original path. Another approach could, of course, be to omit passing the prefix and parse the output of the child and try to substitute, paths but that seems quite error prone to me. Cheers Heiko