Re: [PATCH v3 11/19] dir.c: use a single struct exclude_list per source of excludes

From: Adam Spiers <git@adamspiers.org>
Date: Jan 6, 2013, 15:20 UTC
Message-ID: <20130106152039.GA2396@pacific.linksys.moosehall>
In-Reply-To: <7v1ue0veww.fsf@alter.siamese.dyndns.org>

On Fri, Jan 04, 2013 at 01:03:59PM -0800, Junio C Hamano wrote:

Show 21 quoted lines

> Adam Spiers <git@adamspiers.org> 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.

Show 6 quoted lines

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

Show 20 quoted lines

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