Re: [PATCH 5/5] grep: convert to use the new get_pathspec()

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 5/5] grep: convert to use the new get_pathspec()

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:00

Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted hunk
---
 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.

Re: [PATCH 5/5] grep: convert to use the new get_pathspec()

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:51:00

2011/4/10 Junio C Hamano [off-list ref]:
Nguyễn Thái Ngọc Duy [off-list ref] writes:
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?
Yes, I was blindly reimplementing get_pathspec() behavior...
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.
... and forgot about this.
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help