On 02/24, Brandon Williams wrote:
> It was discovered that when using the --recurse-submodules flag with `git
> grep`
> and `git ls-files` and specifying a relative path when not at the root causes
> the child processes spawned to error out with an error like:
>
> fatal: ..: '..' is outside repository
>
> While true that ".." is outside the scope of the submodule repository, it
> probably doesn't make much sense to the user who gave that pathspec with
> respect to the superproject. Since the child processes that are spawned to
> handle the submodules have some context that they are executing underneath a
> superproject (via the 'super_prefix'), they should be able to prevent dying
> under this circumstance.
>
> This series fixes this bug in both git grep and git ls-files as well as
> correctly formatting the output from submodules to handle the relative paths
> with "..".
>
> One of the changes made to fix this was to add an additional flag for the
> parse_pathspec() function in order to treat all paths provided as being from
> the root of the repository. I hesitantly selected the name
> 'PATHSPEC_FROMROOT'
> but I'm not fond of it since its too similar to the pathspec magic define
> 'PATHSPEC_FROMTOP'. So I'm open for naming suggestions.
>
> Brandon Williams (5):
> grep: illustrate bug when recursing with relative pathspec
> pathspec: add PATHSPEC_FROMROOT flag
> grep: fix bug when recuring with relative pathspec
> ls-files: illustrate bug when recursing with relative pathspec
> ls-files: fix bug when recuring with relative pathspec
>
> builtin/grep.c | 8 --
> builtin/ls-files.c | 8 --
> pathspec.c | 2 +-
> pathspec.h | 2 ++
> t/t3007-ls-files-recurse-submodules.sh | 50
> ++
> t/t7814-grep-recurse-submodules.sh | 42
> 6 files changed, 107 insertions(+), 5 deletions(-)
>
Turns out that this series doesn't address all of the issues. This
series also seems to introduce broken behavior when recursing from a
subdirectory. So I need to think about this problem a little bit more
and reroll.
--
Brandon Williams