Re: [PATCH 09/21] tree_entry_interesting(): support depth limit

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

 



Nguyán ThÃi Ngác Duy  <pclouds@xxxxxxxxx> writes:

>  static const char *get_mode(const char *str, unsigned int *modep)
> @@ -557,8 +558,13 @@ int tree_entry_interesting(const struct name_entry *entry,
>  	int pathlen, baselen = base->len;
>  	int never_interesting = -1;
>  
> -	if (!ps || !ps->nr)
> -		return 1;
> +	if (!ps->nr) {
> +		if (!ps->recursive || ps->max_depth == -1)
> +			return 1;
> +		return !!within_depth(base->buf, baselen,
> +				      !!S_ISDIR(entry->mode),
> +				      ps->max_depth);
> +	}

Back in 1d848f6 (tree_entry_interesting(): allow it to say "everything is
interesting", 2007-03-21), a new return value "2" was introduced to allow
this function to tell the caller that all the remaining entries in the
tree object the caller is feeding the entries to this function _will_
match.  This was to optimize away expensive pathspec matching done by this
function.

In that version, "no pathspec" case wasn't changed to return 2 but still
returned 1 ("I tell you that this does not match; call me with the next
entry").  We could have changed it to return 2, but the overhead was only
a call to a function that checks the number of pathspecs and was not so
bad.

But shouldn't we start returning 2 by now?  It is not that returning 1 was
a more correct thing to do to begin with.

When depth check is in effect, the result depends on the mode of the
entry, so we cannot short-circuit by returning 2, but at least we should
do so when (max_depth == -1), no?

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