Re: Supporting `git add -a <exclude submodules>`

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2023, 21:36 UTC
Message-ID: <xmqqo7gxx76g.fsf@gitster.g>
In-Reply-To: <CAMmZTi-xOWxpzL1SvErgri0_gwvED5Vu2NfeGVcW7jCN8gyEDQ@mail.gmail.com>

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?