Joanna Wang <jojwang@google.com> 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?
Show 5 quoted lines
> 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?
Joanna Wang