On Mon, Jul 10, 2017 at 11:58 AM, Durham Goode <dur...@fb.com> wrote: > > > On 7/10/17 11:55 AM, Martin von Zweigbergk wrote: >> >> On Mon, Jul 10, 2017 at 11:45 AM, Durham Goode <dur...@fb.com> wrote: >>> >>> On 7/10/17 10:01 AM, Martin von Zweigbergk wrote: >>>> >>>> >>>> (For Durham) >>>> >>>> On Sat, Jul 8, 2017 at 4:29 PM, Gregory Szorc <gregory.sz...@gmail.com> >>>> wrote: >>>>> >>>>> >>>>> # HG changeset patch >>>>> # User Gregory Szorc <gregory.sz...@gmail.com> >>>>> # Date 1499555309 25200 >>>>> # Sat Jul 08 16:08:29 2017 -0700 >>>>> # Node ID 94f98bc84936defadb959e31012555dba170d8cd >>>>> # Parent a2867557f9c2314aeea19a946dfb8e167def4fb8 >>>>> dirstate: integrate sparse matcher with _ignore (API) >>>> >>>> >>>> >>>> Why does sparse do it this way instead of intersecting the sparse >>>> matcher with the user's matcher? >>> >>> >>> >>> I'm not sure I understand the question. What is the "user's matcher" >>> here? >>> The ignore matcher? >> >> >> I mean the matcher the user may have provided on the command line (or >> match.always() by default), as in "hg status dir/" (where the matcher >> would be "relpath:dir"). >> >>> >>> This code produces a matcher that returns true for any file that should >>> be >>> ignored. Since both hgignore files and sparse-ignored files should be >>> ignored, I'm not sure how that could be expressed with intersection of >>> those >>> two matchers? >> >> >> For narrowhg, we did it the other way around: filtering in instead of >> filtering out. So if the narrowspec (like sparse config, IIUC) says to >> include foo/ and bar/ and the user provides 'glob:*c', we'd intersect >> that and list *.c files in those two directories (recursively). > > > I'd have to look at the code to be specific, but I think the dirstate ignore > logic covers more cases than the user provided matcher logic. I'd be > surprised if all commands that hit dirstate.ignore also happened to take > patterns at the command level.
If they don't, then the sparse matcher can be passed as is. > It just seemed cleaner to have a unified > matcher for ignored files at the repo level. The user specific matcher can > always be added on top of it later for commands that take patterns. For narrow, we have to apply the matcher when walking the manifest too. The user can pass a matcher to e.g. "hg status -c ." or "hg files -r ." and in those cases we need to intersect the narrow matcher with the user-supplied one. It seemed more natural to do the same for dirstate walks. It also seems simpler to control which directories are visited if using a positive matcher than a negative one. For example, let's say the narrow matcher is path:dir/. The narrowhg code will then restrict the walk to visit only the root directory, dir/, and subdirectories of dir/ (both for manifest walks and dirstate walks). I think we can simply make negatematcher's visitdir return False iff the narrow/sparse matcher returns 'all', so it's probably easy to get it to work. It still seems more natural to me to match what should be included. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
