Nguyán ThÃi Ngác Duy <pclouds@xxxxxxxxx> writes:
> ---
> builtin/grep.c | 10 +---------
> 1 files changed, 1 insertions(+), 9 deletions(-)
>
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 2826ca8..af16deb 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -734,7 +734,6 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> const char *show_in_pager = NULL, *default_pager = "dummy";
> struct grep_opt opt;
> struct object_array list = OBJECT_ARRAY_INIT;
> - const char **paths = NULL;
> struct pathspec pathspec;
> struct string_list path_list = STRING_LIST_INIT_NODUP;
> int i;
> @@ -956,14 +955,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> verify_filename(prefix, argv[j]);
> }
>
> - if (i < argc)
> - paths = get_pathspec_old(prefix, argv + i);
> - else if (prefix) {
> - paths = xcalloc(2, sizeof(const char *));
> - paths[0] = prefix;
> - paths[1] = NULL;
> - }
> - init_pathspec(&pathspec, paths);
> + get_pathspec(&pathspec, prefix, argc - i, argv + i);
This assumes that the new API function will default to "if run without
pathspec, the calling command wants to limit to cwd", doesn't it?
That is why I mentioned that the caller would need to pass a hint as to
what should happen in that case in my earlier message. Probably the new
API function should be something like:
setup_pathspec(&pathspec, prefix, argc, argv, opts)
where opts is a bitmask to carry that hint (or a pointer to a structure
that caller to carry a set of hints richer than a bitmask can express),
and "add -u" and "grep" should set PATHSPEC_DEFAULT_LOCAL in the bitmask.
The call to setup_pathspec() from the log family would not want "no user
specified pathspec means limited to local" semantics.
Then when somebody wants to flip the "add -u" default in future versions,
the call from "add -u" codepath can instead use PATHSPEC_DEFAULT_TREEWIDE
(or perhaps the lack of PATHSPEC_DEFAULT_LOCAL bit may mean tree-wide)
there.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html