Joanna Wang <jojwang@xxxxxxxxxx> writes:
>> choose among attr:submodule, attr:type=<what>, attr:bits=<permbits>, decide what keyword to use
> Whatever we choose, do we want to block these keywords from being used
> by folks in their .gitattributes files?
> That would break any existing usage of the keywords. Is this a concern?
> Option A: To keep things working, we could add this support for attr,
> but then always prioritize whatever is set in .gitattributes. So this
> new behavior would only be triggered if the keywords (e.g.
> "submodule", "type", "bits") aren't set in .gitattributes (or w/e list
> of attributes are being read).
Without thinking things through, I think this sounds easier to
explain to the users. I have to wonder how one would implement such
override, though. Suppose we are doing attr:bits=160000, so we ask
git_check_attr() about "bits" attribute. In collect_some_attrs(), we
will have "bits" in the check[] array. We prepare the attr_stack
and fill(), which would go grab whatever is defined in the
attributes system. We'll lstat() or do the equivalent conversion
from the tree_entry.mode to permission bits only if the attributes
system has nothing to say for that "bits" attribute. I think a few
key things that needs to be thought out are:
(1) where in that callchain would we intercept and insert our own
"bits" value based on the filesystem property?
(2) does collect_some_attrs() or git_check_attr() leave enough
information in check[] to tell between [a] the attr stack had
no opinion on "bits" attribute and [b] the attr stack
explicitly said "bits" attribute is unspecified?
