Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:55:39
Adam Spiers [off-list ref] writes:
quoted hunk
diff --git a/builtin/clean.c b/builtin/clean.c index 0c7b3d0..bd18b88 100644 --- a/builtin/clean.c +++ b/builtin/clean.c@@ -97,9 +97,10 @@ int cmd_clean(int argc, const char **argv, const char *prefix) if (!ignored) setup_standard_excludes(&dir); + add_exclude_list(&dir, EXC_CMDL); for (i = 0; i < exclude_list.nr; i++) add_exclude(exclude_list.items[i].string, "", 0, - &dir.exclude_list[EXC_CMDL]); + &dir.exclude_list_groups[EXC_CMDL].ary[0]);
This looks somewhat ugly for two reasons.
* The abstraction add_exclude() offers to its callers is just to
let them add one pattern to the list of patterns for the kind
(here, EXC_CMDL); why should they care about .ary[0] part? Are
there cases any sane caller (not the implementation of the
exclude_list_group machinery e.g. add_excludes_from_... function)
may want to call it with .ary[1]? I do not think of any.
Shouldn't the public API function add_exclude() take a pointer to
the list group itself?
* When naming an array of things, we tend to prefer naming it
type thing[count]
so that the second element can be called "thing[2]" and not
"things[2]". dir.exclude_list_group[EXC_CMDL] reads beter.
quoted hunk
diff --git a/builtin/ls-files.c b/builtin/ls-files.c index ef7f99a..c448e06 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c@@ -420,10 +420,10 @@ static int option_parse_z(const struct option *opt, static int option_parse_exclude(const struct option *opt, const char *arg, int unset) { - struct exclude_list *list = opt->value; + struct exclude_list_group *group = opt->value; exc_given = 1; - add_exclude(arg, "", 0, list); + add_exclude(arg, "", 0, &group->ary[0]);
This is another example where the caller would wish to be able to say add_exclude(arg, "", 0, group); instead.