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

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 4/14/20 10:47 AM, Alex Bennée wrote:
> 
> Markus Armbruster <armbru@redhat.com> writes:
> 
>> Eric Blake <eblake@redhat.com> writes:
>>
>>> On 4/13/20 4:32 PM, Alex Bennée wrote:
>>>>
>>>> Eric Blake <eblake@redhat.com> 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 <alex.bennee@linaro.org>
>>>>>> ---
>>>>>>     .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).