Re: git 2.34.0: Behavior of `**` in gitignore is different from previous versions.

[Derrick Stolee <stolee@gmail.com>]

On 11/19/2021 3:05 PM, Johannes Sixt wrote:
> Am 19.11.21 um 15:51 schrieb Derrick Stolee:
>> What is unclear to me is what exactly "match a directory" means.
>> If we ignore a directory, then we ignore everything inside it (until
>> another pattern says we should care about it), but the converse
>> should also hold: if we have a pattern like "!data/**/", then that
>> should mean "include everything inside data/<A>/ where <A> is any
>> directory name".
>>
>> My inability to form a mental model where the existing behavior
>> matches the documented specification is an indicator that this was
>> changed erroneously. A revert patch is included at the end of this
>> message.
>>
>> If anyone could help clarify my understanding here, then maybe
>> there is room for improving the documentation.
> 
> You form a wrong mental model when you start with the grand picture of a
> working tree. That is, when you say
> 
> - here I have theeeeeese many files and directories,
> - and I want to ignore some: foo/**/,
> - but I don't want to ignore others: !bar/**/.
> 
> This forms the wrong mental model because that is not how Git sees the
> working tree: it never has a grand picture of all of its contents.
> 
> Git only ever sees the contents of one directory. When Git determines
> that a sub-directory is ignored, then that one's contents are never
> inspected, and there is no opportunity to un-ignore some of the
> sub-directory's contents.

So the problem is this: I want to know "I have a file named <X>, and
a certain pattern set, does <X> match the patterns or not?" but in
fact it's not just "check <X> against the patterns in order" but
actually "check every parent directory of <X> in order to see if
any directory is unmatched, which would preclude any later matches
to other parents of <X>"

So really, to check a path, we really want to first iterate on the
parent directories. If we get a match on a positive pattern on level
i, then we check level (i+1) for a match on a negative pattern. If
we find that negative pattern match, then continue. If we do not see
a negative match, then we terminate by matching the entire path <X>.

I'm still not seeing a clear way of describing the matching procedure
here for a single path, and that's fine. Me understanding is not a
necessary condition for fixing this bug.

Thanks,
-Stolee