Re: top-level gitignore considered harmful

[Tomas Carnecky <tomas.carnecky@gmail.com>]

On Thu, 29 Mar 2012 17:11:36 -0400, Jeff King <peff@peff.net> 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