Re: [PATCH] .gitignore: include common build sub-directories

[Philippe Mathieu-Daudé]

On 4/14/20 10:47 AM, Alex Bennée wrote:
> Markus Armbruster <address@hidden> writes:
>
> > Eric Blake <address@hidden> writes:
> >
> > > On 4/13/20 4:32 PM, Alex Bennée wrote:
> > > > Eric Blake <address@hidden> writes:
> > > >
> > > > > On 4/13/20 11:29 AM, Alex Bennée wrote:
> > > > > > As out-of-tree builds become more common (or rather building in a
> > > > > > subdir) we can add a lot of load to "git ls-files" as it hunts down
> > > > > > sub-directories that are irrelevant to the source tree. This is
> > > > > > especially annoying if you have a prompt that attempts to summarise
> > > > > > the current git status on command completion.
> > > > > > Signed-off-by: Alex Bennée <address@hidden>
> > > > > > ---
> > > > > >     .gitignore | 2 ++
> > > > > >     1 file changed, 2 insertions(+)
> > > > > > diff --git a/.gitignore b/.gitignore
> > > > > > index 0c5af83aa74..7757dc08a08 100644
> > > > > > --- a/.gitignore
> > > > > > +++ b/.gitignore
> > > > > > @@ -141,6 +141,8 @@ cscope.*
> > > > > >     tags
> > > > > >     TAGS
> > > > > >     docker-src.*
> > > > > > +build
> > > > > > +builds
> > > > >
> > > > > Would 'build-*' be worth adding as well?
> > > >
> > > > Sure - I'll add it to v2.
> > >
> > > Or even consolidate it into a single pattern: build* (which would
> > > allow 'build', 'builds', 'build1', 'build23', 'build-fedora',
> > > 'build-bug1234', ...)
> >
> > The looser the pattern, the higher the risk of unwanted matches.
> >
> > Would be less of an issue if we had a cleaner source root directory.
>
> True but as of now we don't have anything matching bu* so I think build*
> is fairly safe. I have ran into problems with over lax .gitignore
> stanzas before but I don't think it's taken too long to figure out what
> was going on. It's not like having a build subdir isn't a common
> "out-of-tree" build idiom.

We can restrict to directories using "build*/":

GITIGNORE(5)

·   If the pattern ends with a slash, it is removed for the
    purpose of the following description, but it would only
    find a match with a directory. In other words, foo/ will
    match a directory foo and paths underneath it, but will
    not match a regular file or a symbolic link foo (this is
    consistent with the way how pathspec works in general in
    Git).