From: Benoit SIGOURE Date: Mon, 15 Oct 2007 10:53:11 GMT Subject: Re: git-svn and submodules Message-ID: In-Reply-To: <86lka4ofb8.fsf@lola.quinscape.zz> On Oct 15, 2007, at 12:14 PM, David Kastrup wrote: > Benoit SIGOURE writes: > >> This week I'm probably going to start to dive in git-svn by >> implementing simpler things first: >> - 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) > > Well, then this should be fixed in git general, by sorting the ignores > (wildcards in the first place where they can match), and then just > moving those patterns that can actually match according to sort order > to the list of fnmatch candidates (and moving those files that can't > match anymore die to the sort order out again). > > I don't think that the final "solution" for avoiding a lousy global > O(n^2) algorithm is to replace it with lousy local O(n^2) algorithms > and just hope for smaller values of n. That's entirely true, it's more of a workaround than a real solution. Anyways, there could be other situations in which someone would like to generate the .gitignore instead of using .git/info/ exclude, so this feature could be useful anyways. I can try to address this issue later, if I have enough free time in my hands to do so. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory