Re: [PATCH v3 3/5] grep: fix bug when recursing with relative pathspec

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 21, 2017, 11:47 UTC
Message-ID: <CACsJy8Cu8cgtJzDDM09GoJr5Ny+G+nP17GjZjXng6ZPQv9eXXg@mail.gmail.com>
In-Reply-To: <20170317172257.4690-4-bmwill@google.com>

On Sat, Mar 18, 2017 at 12:22 AM, Brandon Williams <bmwill@google.com> wrote:

> With these two pieces of information a child process can correctly
> interpret the pathspecs provided by the user as well as being able to
> properly format its output relative to the directory the user invoked
> the original command from.

This part can stand alone as a separate patch right? It would help focus on the pathspec thingy first.

Show 15 quoted lines

> @@ -399,13 +405,12 @@ static void run_pager(struct grep_opt *opt, const char *prefix)
>  }
>
>  static void compile_submodule_options(const struct grep_opt *opt,
> -                                     const struct pathspec *pathspec,
> +                                     const char **argv,
>                                       int cached, int untracked,
>                                       int opt_exclude, int use_index,
>                                       int pattern_type_arg)
>  {
>         struct grep_pat *pattern;
> -       int i;
>
>         if (recurse_submodules)
>                 argv_array_push(&submodule_options, "--recurse-submodules");

Side note. It would be awesome if you could make parse_options() (or a new function) do the reverse process: given a 'struct option' with valid data, spit out argv_array. Less worrying about git-grep having new option but not passed to subgrep by accident. You can have a new flag to tell it to ignore certain options if you don't want to pass all.

-- 
Duy