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

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Oct 6, 2012, 06:43 UTC
Message-ID: <CACsJy8Cn0rAV+u+8tzD2HOm1XkfKBPkFJVrPQAojMBtYe6wxRg@mail.gmail.com>
In-Reply-To: <7vk3v4rwkv.fsf@alter.siamese.dyndns.org>

On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

>> 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.
>
>    ...
>
>    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.

Exactly why we should not make "path/ attr" no-op. If we want to make it meaningful some day in future, I don't think we want those no-ops lay around and suddenly cause changes in behavior with a new version of git.

Show 5 quoted lines

> 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).

>From a user perspective, the thinking through portion is usually less

than the try-and-see.

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

-- 
Duy