Re: top-level gitignore considered harmful

On Thu, 29 Mar 2012 17:11:36 -0400, Jeff King [off-list ref] wrote:

So we were sitting around chatting today about how slow "git status" is
in the gigantic WebKit repository (because really, what else would one
chat about?). Carlos noticed that git spends a lot of time in the
gitignore code path.  It turns out that the WebKit repository has a
couple hundred excludes in the top-level .gitignore, many of which are
for specific files deep in the repository.

Since these patterns are compared via fnmatch(), we have to process them
linearly for each entry[1]. And since the patterns are at the top level,
we check them for each of the ~180,000 files in the repository. So "git
status" will do O(m*n) work, where "m" is the number of patterns and "n"
is the number of files in the repository. And as a project grows over
time, one might expect "m" to be some constant factor of "n". So this is
really O(n^2) (albeit with some mitigating constant at the front).

Many months ago I noticed that as well, when somebody came to #git and
complained that git status is slow (it toook *many* seconds for him). We
tracked that down to the fact that his .gitignore contained hundreds of
entries. He basically did `git ls-files --other >> .gitignore`, so his
.gitignore included every single object file and all other build artefacts.
I told him to use wildcards and `git status` became usable again.

tom