Re: [PATCH 0/6] [RFC] config.c: use struct for config reading state

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2023, 19:36 UTC
Message-ID: <xmqqbkl4xsj2.fsf@gitster.g>
In-Reply-To: <kl6lfsagifpc.fsf@chooglen-macbookpro.roam.corp.google.com>

Glen Choo <chooglen@google.com> writes:

> ... In the spirit of
> libification, this feels like a kludge, though, since we'd be reverting
> to using "struct repository" for more things instead of using more
> well-scoped interfaces.

If you include "populate from system-wide, per-user, and repository specific configuration files" as part of the API being libified, your configsets cannot avoid being tied to a repository. But I do not think the reader needs to be in the repository.

> IMO a better future for the config_set API would
> be to move it into configset.c or something, where only users who want
> the low level API would use it and everyone else would just pretend it
> doesn't exist.

Isn't the use of the reader object purely transitory while you populate the keys and values in a configset from a single file? At the layer to read and populate a configset from a single "source" file, you still do not need repository.

Only when you say "I have a 'repo' instance and I want to read the config variables from appropriate places", you call such a "read and populate configset from a single source" helper three or four times to populate repo->config. Once a configset is populated, it or its contents do not depend on the reader instance to function, so I do not see how it benefits to have the reader in the repository object.