From: Phillip Wood <phillip.wood123@gmail.com>
Date: Fri, 07 Mar 2025 10:37:42 GMT
Subject: Re: [PATCH v3 1/8] config: teach repo_config to allow `repo` to be NULL
Message-ID: <162727f9-fb65-4bae-87fb-48fd5527064c@gmail.com>
In-Reply-To: <xmqqcyeuhwqb.fsf@gitster.g>

On 06/03/2025 17:53, Junio C Hamano wrote:
> Usman Akinyemi <usmanakinyemi202@gmail.com> writes:
 >
> I am wondering if we should describe the effect we want out of the
> design more prominently than the way we try to obtain the effect
> here.  In other words, instead of (rather, in addition to) saying
> that we call helper X, wouldn't it be more helpful to future
> developers why we call X, to convey the intent, so that they know
> how to adjust when for example what X does change or X even
> disappears?  E.g.,
> 
> 	When repo==NULL, skip reading the per-repository
> 	configuration file but still use the system- and globa-
> 	configuration, by calling X.  Note that this ignores
> 	one-time configuration override "git -c var=val" given from
> 	the command line.  The only use case the feature to allow
> 	passing repo==NULL was designed for is to support handling
> 	"git foo -h" (which lets git.c:run_builtin() to pass NULL
> 	and have the cmd_foo() call repo_config() before calling
> 	parse_options() to notice "-h", give help and exit) for a
> 	command that ordinarily require a repository, so this
> 	limitation may be OK (but if needed you are welcome to fix
> 	it).

I think that would be very helpful as it makes it clear why we don't 
care about config on the commandline for this series.

Best Wishes

Phillip

> That way, folks who are planning to update read_veriy_early_config()
> so that it pays attention to the "git -c var=val" in the future will
> be rest assured that they won't be breaking this caller with their
> planned change.
> 
> Of course I didn't spend enough brainpower to make the above comment
> more concise and to the point, which the final version should be,
> but hopefully you got the idea.
> 
> Thanks.
> 
>