Re: [PATCH v3 04/11] unpack-trees: introduce preserve_ignored to unpack_trees_options
- From
Elijah Newren <newren@gmail.com>
- Date
- Oct 4, 2021, 13:45 UTC
- Message-ID
- <CABPp-BFE_5zPCZY8adJSQchdQzxq3uH-oma-S=_Sw0OUXx03OQ@mail.gmail.com>
- In-Reply-To
- <87k0ivpzfx.fsf@evledraar.gmail.com>
On Sat, Oct 2, 2021 at 2:07 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > On Fri, Oct 01 2021, Elijah Newren wrote: >
...
Show 20 quoted lines
> > So maybe I'll submit some patches on top that rip these direct members
> > out of of unpack_trees_options and push them inside some opaque
> > struct.
>
> Sure, that sounds good. I only had a mild objection to doing it in a way
> where you'll need that sort of code I removed in the linked commit in
> prep_exclude() because you were trying not to expose that at any cost,
> including via some *_INIT macro. I.e. if it's private we can just name
> it "priv_*" or have a :
>
> struct dont_touch_this {
> struct dir_struct dir;
> };
>
> Which are both ways of /messaging/ that it's private, and since the
> target audience is just the rest of the git.git codebase I think that
> ultimately something that 1) sends the right message 2) makes accidents
> pretty much impossible suffices. I.e. you don't accidentally introduce a
> new API user accessing a field called "->priv_*" or
> "->private_*". Someone will review those patches...An internal struct with all the members meant to be internal-only provides nearly all the advantages that I was going for with the opaque struct, while also being a smaller change than what I was thinking of doing. I like that idea; thanks for the suggestion.