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