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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nguyán ThÃi Ngác Duy  <pclouds@xxxxxxxxx> 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.


--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]