Re: [PATCH v3 1/8] config: teach repo_config to allow `repo` to be NULL
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Mar 7, 2025, 10:37 UTC
- 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:
>
Show 20 quoted lines
> 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
Show 12 quoted lines
> 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. > >