{"thread":{"id":"60384","subject":"Re: Supporting `git add -a <exclude submodules>`","startedAt":"2023-10-17T20:59:44Z","lastAt":"2023-10-17T21:36:46Z","messageCount":2,"participants":["Joanna Wang","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"483367","messageId":"CAMmZTi-xOWxpzL1SvErgri0_gwvED5Vu2NfeGVcW7jCN8gyEDQ@mail.gmail.com","threadId":"60384","inReplyTo":null,"subject":"Re: Supporting `git add -a <exclude submodules>`","fromName":"Joanna Wang","fromEmail":"jojwang@google.com","sentAt":"2023-10-17T20:59:30Z","receivedAt":"2023-10-17T20:59:44Z","isPatch":false,"sender":{"key":"jojwang@google.com","avatar":"https://avatars.githubusercontent.com/u/120585822?v=4"},"body":"> choose among attr:submodule, attr:type=<what>, attr:bits=<permbits>, decide what keyword to use\nWhatever we choose, do we want to block these keywords from being used\nby folks in their .gitattributes files?\nThat would break any existing usage of the keywords. Is this a concern?\n\nOption A: To keep things working, we could add this support for attr,\nbut then always prioritize whatever is set in .gitattributes. So this\nnew behavior would only be triggered if the keywords (e.g.\n\"submodule\", \"type\", \"bits\") aren't set in .gitattributes (or w/e list\nof attributes are being read).\n\nOption B: Or we could add this new behavior for `attr-bits:<permbits>`\nor just `bits:<permbits>`.\n\nI personally don't see big UX differences between A and B. Any opinions on this?\n"},{"id":"483370","messageId":"xmqqo7gxx76g.fsf@gitster.g","threadId":"60384","inReplyTo":"CAMmZTi-xOWxpzL1SvErgri0_gwvED5Vu2NfeGVcW7jCN8gyEDQ@mail.gmail.com","subject":"Re: Supporting `git add -a <exclude submodules>`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-17T21:36:39Z","receivedAt":"2023-10-17T21:36:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joanna Wang <jojwang@google.com> writes:\n\n>> choose among attr:submodule, attr:type=<what>, attr:bits=<permbits>, decide what keyword to use\n\n> Whatever we choose, do we want to block these keywords from being used\n> by folks in their .gitattributes files?\n> That would break any existing usage of the keywords. Is this a concern?\n\n> Option A: To keep things working, we could add this support for attr,\n> but then always prioritize whatever is set in .gitattributes. So this\n> new behavior would only be triggered if the keywords (e.g.\n> \"submodule\", \"type\", \"bits\") aren't set in .gitattributes (or w/e list\n> of attributes are being read).\n\nWithout thinking things through, I think this sounds easier to\nexplain to the users.  I have to wonder how one would implement such\noverride, though.  Suppose we are doing attr:bits=160000, so we ask\ngit_check_attr() about \"bits\" attribute. In collect_some_attrs(), we\nwill have \"bits\" in the check[] array.  We prepare the attr_stack\nand fill(), which would go grab whatever is defined in the\nattributes system.  We'll lstat() or do the equivalent conversion\nfrom the tree_entry.mode to permission bits only if the attributes\nsystem has nothing to say for that \"bits\" attribute.  I think a few\nkey things that needs to be thought out are:\n\n (1) where in that callchain would we intercept and insert our own\n     \"bits\" value based on the filesystem property?\n\n (2) does collect_some_attrs() or git_check_attr() leave enough\n     information in check[] to tell between [a] the attr stack had\n     no opinion on \"bits\" attribute and [b] the attr stack\n     explicitly said \"bits\" attribute is unspecified?\n\n"}]}