Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 1/2] Reimplement read_tree_recursive() using tree_entry_interesting()

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:52

Nguyễn Thái Ngọc Duy  [off-list ref] writes:
read_tree_recursive() uses a very similar function, match_tree_entry, to
tree_entry_interesting() to do its path matching. This patch kills
match_tree_entry() in favor of tree_entry_interesting().
...
+int read_tree_recursive(struct tree *tree,
+			const char *base, int baselen,
+			int stage, const char **match,
+			read_tree_fn_t fn, void *context)
+{
+	struct strbuf sb = STRBUF_INIT;
+	struct pathspec pathspecs;
+	int i, ret;
+
+	init_pathspec(&pathspecs, match);
+	for (i = 0; i < pathspecs.nr; i++)
+		pathspecs.items[i].has_wildcard = 0;
I think this is going in the right direction, but I have been hoping that
we would eventually stop passing "const char **" pointers around when the
caller specifies what are the set of paths that are to be affected.

We still retain "const char **raw" field in "struct pathspec" even after
your previous series, but I think that is because there still are too many
callers that already have a "struct pathspec *pathspec" but pass only that
field (i.e. "pathspec->raw") down the callchain, and converting all the
callees was a bit too much to chew on during the previous series (which I
consider is fine and sane).  The eventual goal should be for such callers
to pass the "pathspec" itself, so that the callees can learn wildcarding
and all the "magic" fun stuff later.

As read_tree_recursive() has only 6 external callers, it may be a good
place to start that conversion.  Another offender is fill_directory() in
dir.c that are used in 6 places.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help