On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html