On Mon, 15 Oct 2007, Benoit SIGOURE wrote: > > - 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
