[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