On Fri, Jan 04, 2013 at 01:03:59PM -0800, Junio C Hamano wrote:
> Adam Spiers <git@xxxxxxxxxxxxxx> writes:
>
> > 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?
Because the caller has to decide which exclude list the new exclude
should be added to; that is how it has been for a long time, and I am
not proposing we change that.
There are currently three callers:
builtin/clean.c: cmd_clean()
builtin/ls-files.c: option_parse_exclude()
dir.c: add_excludes_from_file_to_list()
The first two add to EXC_CMDL, but the latter could be adding to
numerous different possible lists, e.g.
- .git/info/exclude (EXC_FILE)
- core.excludesfile (EXC_FILE)
- any of the per-directory .gitignore lists (EXC_DIRS)
> 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]?
Effectively yes, although it is not written like ".ary[1]". For
example prep_exclude() calls add_excludes_from_file_to_list() for each
new .gitignore file
> Shouldn't the public API function add_exclude() take a pointer to
> the list group itself?
Typically EXC_DIRS and EXC_FILE will contain excludes from multiple
sources, whereas EXC_CMDL will contain excludes from a single source.
Therefore when transitioning to exclude_list_groups, I had to make a
choice whether to keep EXC_CMDL as a singleton list, or split it out
into a separate field in struct dir_struct, e.g.:
struct exclude_list exclude_list_cmdl;
struct exclude_list exclude_list[2];
#define EXC_DIRS 0
#define EXC_FILE 1
I decided it was cleaner to use a singleton list, because this
preserved the design that excludes in earlier members of
exclude_list[3] take priority over excludes in later members of
exclude_list[3]. That way, this loop in last_exclude_matching():
for (i = EXC_CMDL; i <= EXC_FILE; i++) {
still makes sense.
> * 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.
OK, I will change that.
> > 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.
Why? The caller needs to decide which exclude list the exclude should
go on, because that determines matching priority. Specifying an
exclude_list_group is insufficient information to determine that.
--
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