Karthik Nayak <[email protected]> writes:
> /*
> - * A call-back given to for_each_ref(). Filter refs and keep them for
> + * A call-back given to for_each_ref(). Filter refs and keep them for
> * later object processing.
> */
> -static int grab_single_ref(const char *refname, const unsigned char *sha1,
> int flag, void *cb_data)
> +int ref_filter_handler(const char *refname, const unsigned char *sha1, int
> flag, void *cb_data)
> {
I am not sure if this is a good external interface, i.e. to expect
callers of ref-filter API to do this:
prepare cbdata;
for_each_ref(ref_filter_handler, &cbdata);
It might be better to expect callers to do this instead:
prepare cbdata;
filter_refs(for_each_ref, &cbdata);
i.e. introducing a new "filter_refs()" function as the entry point
to the ref-filter API. The filter_refs() entry point may internally
use ref_filter_handler() that will be file-scope static to ref-filter.c
and at that point the overly generic "-handler" name would not bother
anybody ;-) but more importantly, then you can extend the function
signature of filter_refs() not to be so tied to for_each_ref() API.
It could be that the internals of cbdata may not be something the
callers of filter-refs API does not even have to know about, in
which case the call might even become something like:
struct ref_array refs = REF_ARRAY_INIT;
const char **ref_patterns = { "refs/heads/*", "refs/tags/*", NULL};
filter_refs(&refs, for_each_rawref, ref_patterns);
/* now "refs" has the result, the caller uses them */
for (i = 0; i < refs.nr; i++)
refs.item[i];
Just a thought.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
