Re: [PATCH 04/10] attr: more matching optimizations from .gitignore

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2012, 05:36 UTC
Message-ID: <7vk3v4rwkv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8BWJg0sr-6iG4LwJjkSM46=CBgddDac4dDR2o3HZ8_25g@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Show 25 quoted lines

> On Sat, Oct 6, 2012 at 1:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> +Unlike `.gitignore`, negative patterns are not supported.
>>> +Patterns that match directories are also not supported.
>>
>> Is "are not supported" the right phrasing?
>>
>> I think it makes perfect sense not to forbid "!path attr1", because
>> it is unclear what it means (e.g. "path -attr1" vs "path !attr1").
>> So I would say "Negative patterns are forbidden as they do not make
>> any sense".
>
> OK
>
>> But for the latter, I think it makes a lot more sense to just accept
>> "path/ attr1" and doing nothing.  The user requests to set an
>> attribute to "path" that has to be a directory, and there is nothing
>> wrong in such a request in itself.  But nothing in git asks for
>> attributes for directories (because we do not track directories),
>> and such a request happens to be a no-op.
>
> Or the user might think "path/ attr1" sets attr1 for all files under
> "path/" because it does not make sense to attach attributes to a
> directory in git.

Hrm, isn't that reasoning flawed at least for two reasons?

 - One reasonable way to conceptually unify excludes and attributes
   is to consider "being ignored" as just one kind of attribute. If
   you imagine an ideal world where we did not have any .gitignore,
   an entry "path/" in .gitignore would be "path/ excluded", and an
   entry "!path/" in .gitignore would be "path/ -excluded".  Realize
   that on the exclude side, we are already assigning an "attribute"
   to a directory.

 - Setting attr1 to everything in path is spelled "path1/**/* attr1"
   if we are to adopt "/**/ is zero or more intermediate levels"
   enhancement.

   We may not have a need to assign a real attribute to a directory
   right now, because nothing in Git asks for an attribute for a
   directory. But that does not necessarily mean we would never need a
   way to give an attribute to a directory but not to its contents.

If one does not think it through, the "path/ excluded" example might appear that there is no difference between setting exclude to the path itself and setting it to path and everything underneath it, but that comes largely from the nature of "exclude" attribute (think of "exclude" attribute as "exclude itself and everything under it).

There is no reason to assume other attributes we may want to give to a directory share the same "recursive" kind of semantics.