On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
quoted text
>
>  - git svn create-ignore (to create one .gitignore per directory from the
> svn:ignore properties.  This has the disadvantage of committing the .gitignore
> during the next dcommit, but when you import a repo with tons of ignores
> (>1000), using git svn show-ignore to build .git/info/exclude is *not* a good
> idea, because things like git-status will end up doing >1000 fnmatch *per
> file* in the repo, which leads to git-status taking more than 4s on my
> Core2Duo 2Ghz 2G RAM)

Ouch.

That sounds largely unavoidable.. *But*.

Maybe we have a bug here. In particular, we generally shouldn't care about 
the exclude/.gitignore file for ay paths that we know about, which means 
that during an import, we really shouldn't ever even care about 
.gitignore, since all the files are files we are expected to know about.

So yes, in general, "git status" is going to be slow in a tree that has 
been built (since things like object files etc will have to be checked 
against the exclude list! (*)), but if it's a clean import with no 
generated files and only files we already know about, that should not be 
the case.

So maybe we have a totally unnecessary performance issue, and do all the 
fnmatch() on every path, whether we know about it or not?

		Linus

(*) It might be that we could also re-order the exclude list so that 
entries that trigger are moved to the head of the list, because it's 
likely that if you have tons of exclude entries, some of them trigger a 
lot more than others (ie "*.o"), and trying those first is likely a good 
idea.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html