Re: top-level gitignore considered harmful

From: Tomas Carnecky <tomas.carnecky@gmail.com>
Date: Mar 30, 2012, 09:30 UTC
Message-ID: <1333099827-ner-1054@calvin>
In-Reply-To: <20120329211136.GA1112@sigill.intra.peff.net>

On Thu, 29 Mar 2012 17:11:36 -0400, Jeff King <peff@peff.net> wrote:

Show 14 quoted lines

> 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