Re: [PATCH v2 00/32] repository object

From: Stefan Beller <sbeller@google.com>
Date: Jun 12, 2017, 05:24 UTC
Message-ID: <CAGZ79kbtZJd3O1vZBEkqU5_VRs5LmJhxUKtWu4RWTyk5M1r__Q@mail.gmail.com>
In-Reply-To: <20170610060712.foqre5fscaxu3tnx@sigill.intra.peff.net>

On Fri, Jun 9, 2017 at 11:07 PM, Jeff King <peff@peff.net> wrote:

Show 17 quoted lines

> On Fri, Jun 09, 2017 at 05:40:34PM -0700, Jonathan Tan wrote:
>
>> Before I get into the details, I have some questions:
>>
>> 1. I am concerned that "struct repository" will end up growing without
>> bounds as we store more and more repo-specific concerns in it. Could it
>> be restricted to just the fields populated by repo_init()?
>> repo_read_index() will then return the index itself, instead of using
>> "struct repository" as a cache. This means that code using
>> repo_read_index() will need to maintain its own variable holding the
>> returned index, but that is likely a positive - it's better for code to
>> just pass around the specific thing needed between functions anyway, as
>> opposed to passing a giant "struct repository" (which partially defeats
>> the purpose of eliminating the usage of globals).
>
> I think the repository object has to become a kitchen sink of sorts,
> because we have tons of global variables representing repo-wide config.

AFAICT we want to operate on struct 'the_repo' and struct 'the_cmd_options' eventually. In our use case of submodules the submodules would ignore the settings of the main repo, but still accept guidance of the_cmd_config or 'the_config.

> So I have a feeling that we're always going to need some
> big object to hold all that context when doing multi-repo operations in
> a single process.

Well not just one big struct, but two. (or more?)