From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 07 Mar 2023 19:36:49 GMT
Subject: Re: [PATCH 0/6] [RFC] config.c: use struct for config reading state
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.