On Oct 15, 2007, at 12:14 PM, David Kastrup wrote:

quoted text
> Benoit SIGOURE <tsuna@lrde.epita.fr> 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