On Mon, Dec 06 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> In preceding commits the rest of the vreportf() users outside of >> usage.c have been migrated to die_message(), leaving only the >> git_die_config() function added in 5a80e97c827 (config: add >> `git_die_config()` to the config-set API, 2014-08-07). >> >> Let's have its callers call error() themselves if they want to emit a >> message, which is exactly what git_die_config() was doing for them >> before emitting its own die() message. > > I do not quite get this. If git_die_config() has been showing the > message for them, and if the existing callers can just use error(), > why not git_die_config() call error() on behalf of these callers? > >> diff --git a/builtin/fast-import.c b/builtin/fast-import.c >> index 2b2e28bad79..4e2432bb491 100644 >> --- a/builtin/fast-import.c >> +++ b/builtin/fast-import.c >> @@ -3456,9 +3456,10 @@ static void git_pack_config(void) >> } >> if (!git_config_get_int("pack.indexversion", &indexversion_value)) { >> pack_idx_opts.version = indexversion_value; >> - if (pack_idx_opts.version > 2) >> - git_die_config("pack.indexversion", >> - "bad pack.indexversion=%"PRIu32, pack_idx_opts.version); >> + if (pack_idx_opts.version > 2) { >> + error("bad pack.indexversion=%"PRIu32, pack_idx_opts.version); >> + git_die_config("pack.indexversion"); >> + } > > This is exactly what triggered the question above, and the pattern > repeats elsewhere, too. > >> @@ -2550,18 +2552,12 @@ void git_die_config_linenr(const char *key, const char *filename, int linenr) >> key, filename, linenr); >> } >> >> -NORETURN __attribute__((format(printf, 2, 3))) >> -void git_die_config(const char *key, const char *err, ...) >> +NORETURN >> +void git_die_config(const char *key) >> { >> const struct string_list *values; >> struct key_value_info *kv_info; >> >> - if (err) { >> - va_list params; >> - va_start(params, err); >> - vreportf("error: ", err, params); >> - va_end(params); > > I get that we do not want to expose vreportf() to this caller, and I > agree with the goal, but wouldn't it be the matter of calling > get_error_routine() and calling it with err and params here, instead > of losing the whole block? Is that insufficient to avoid toucing > all the callers? I'll fix that in the incoming re-roll. This really didn't belong in this series but a later one. FWIW that change was because like this we'll accurately report the source of the "error" when the function learns to spew <file>:<line> at the user. But for now I'll just have it do as you suggest...