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

2 messages from 2023-10-17 to 2023-10-17. Participants: Joanna Wang, Junio C Hamano.
Thread: https://gitlist.dev/t/60384

## Joanna Wang, 2023-10-17 20:59

Subject: Re: Supporting `git add -a <exclude submodules>`
Message-ID: <CAMmZTi-xOWxpzL1SvErgri0_gwvED5Vu2NfeGVcW7jCN8gyEDQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAMmZTi-xOWxpzL1SvErgri0_gwvED5Vu2NfeGVcW7jCN8gyEDQ%40mail.gmail.com

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

Option B: Or we could add this new behavior for `attr-bits:<permbits>`
or just `bits:<permbits>`.

I personally don't see big UX differences between A and B. Any opinions on this?

```

## Junio C Hamano, 2023-10-17 21:36

Subject: Re: Supporting `git add -a <exclude submodules>`
Message-ID: <xmqqo7gxx76g.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqqo7gxx76g.fsf%40gitster.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?

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


```