[PATCH 11 of 11 sparse] dirstate: integrate sparse matcher with _ignore (API)

Durham Goode durham at fb.com
Mon Jul 10 14:58:55 EDT 2017



On 7/10/17 11:55 AM, Martin von Zweigbergk wrote:
> On Mon, Jul 10, 2017 at 11:45 AM, Durham Goode <durham at 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.szorc at gmail.com>
>>> wrote:
>>>>
>>>> # HG changeset patch
>>>> # User Gregory Szorc <gregory.szorc at 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.  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.


More information about the Mercurial-devel mailing list