[PATCH 3 of 8] ignore: add ui to ignore stack

Durham Goode durham at fb.com
Mon May 18 12:59:25 CDT 2015

On 5/18/15 2:12 AM, Martin von Zweigbergk wrote:
> OK, so that argument didn't fly. How about this:
> I agree that the matcher logic needs to be fast in general, but how 
> often will this particular matcher be called? My guess is that it's 
> only on untracked files and directories (but not on files inside 
> ignored directories). Is that correct? How many such files and 
> directories will reasonably exist? (That last question wasn't 
> rhetorical; I'd be happy to hear if you can find out.)
> Do we at least agree about the UI problem in having a config option 
> that makes the user say they're using sane regexes? I don't think it's 
> a huge problem, but I think it's large enough to do some profiling 
> with hgwatchman on a realistic working copy (and maybe a "worst-case" 
> one).
I'm going to send a patch series with doing it the way you mentioned.  
It's easier to do it that way when doing the feature the way Matt wants 
("include:path/to/ignore" style rules).  We'll deal with the perf it it 
becomes a problem.
> On Sun, May 17, 2015, 20:12 Pierre-Yves David 
> <pierre-yves.david at ens-lyon.org 
> <mailto:pierre-yves.david at ens-lyon.org>> wrote:
>     On 05/16/2015 02:18 AM, Martin von Zweigbergk wrote:
>     > As mentioned elsewhere, I and the other Martin would really like
>     to see
>     > if we can afford (performance-wise) to replace pattern-rewriting
>     with
>     > application of the pattern to a substring. It just seems like
>     the right
>     > thing to do from the user's point of view. At least if done in C and
>     > avoiding string copying, it doesn't seem like a terribly expensive
>     > operation. What else is done in this code path? Stat'ing the files?
>     > Listing files in directory? Seems like that should be more
>     expensive,
>     > but maybe not on warm disk?
>     With watchman, the disk is rarely touched directly.
>     --
>     Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150518/96824865/attachment.html>

More information about the Mercurial-devel mailing list