On 24/11/27 06:44AM, Patrick Steinhardt wrote:
> On Tue, Nov 26, 2024 at 06:57:06PM -0600, Justin Tobler wrote:
> > diff --git a/fetch-pack.c b/fetch-pack.c
> > index fe1fb3c1b7..e7d4f6e6e2 100644
> > --- a/fetch-pack.c
> > +++ b/fetch-pack.c
> > @@ -1877,14 +1877,24 @@ static int fetch_pack_config_cb(const char *var, const char *value,
> > if (!value)
> > return config_error_nonbool(var);
> > if (is_valid_msg_type(msg_id, value))
> > - strbuf_addf(&fsck_msg_types, "%c%s=%s",
> > - fsck_msg_types.len ? ',' : '=', msg_id, value);
> > + strbuf_addf(msg_types, "%c%s=%s",
> > + msg_types->len ? ',' : '=', msg_id, value);
> > else
> > warning("Skipping unknown msg id '%s'", msg_id);
> > return 0;
> > }
> >
> > - return git_default_config(var, value, ctx, cb);
> > + return -1;
> > +}
> > +
> > +static int fetch_pack_config_cb(const char *var, const char *value,
> > + const struct config_context *ctx, void *cb)
> > +{
> > + int ret = fetch_pack_fsck_config(var, value, &fsck_msg_types);
> > + if (ret < 0)
> > + return git_default_config(var, value, ctx, cb);
> > +
> > + return ret;
> > }
> >
> > static void fetch_pack_config(void)
>
> Okay, this now reads a lot nicer. But I'm sceptical whether we should
> return -1 for the case where the value wasn't handled because we now
> cannot discern the case where the function returns an error from the
> case where it simply didn't handle the value.
>
> In fact, we cannot even use positive values right now as far as I can
> see:
>
> - We return 0 on success.
>
> - We return 1 in case `git_config_pathname()` indicates an error.
>
> - We return -1 when there is no value with "fetch.fsck.".
>
> I'd propose to have a look at whether the positive return value from the
> second case is actually used anywhere. If not, we can refactor this case
> so that we always return negative on errors. And then we could further
> adapt the function to return positive in case it didn't handle the
> value.
The `fetch_pack_fsck_config()` function is only used through callback
functions for `git_config()`. The `config_fn_t` callback is expected to
return 0 for success, or -1 if the variable could not be parsed
properly. Taking a look at `configset_iter()`, in practice any return
value >= 0 is treated as success.
This means that because the `git_config_pathname()` errors in
`fetch_pack_fsck_config()` return 1, an error is printed, but the
operation is able to proceed.
# Skip list is missing path value.
$ git -c fetch.fsck.skipList fetch
error: missing value for 'fetch.fsck.skiplist'
<fetch continues...>
This skip list flag behavior is consistent across other fsck operations.
Changing it here to return -1 would make config parsing more strict and
result in a missing skip list path causing the whole operation to die.
Since returning 1 is treated as a success anyway, we could change it to
return 0. This would result in functionally the same behavior and free
up `fetch_pack_fsck_config()` to return 1 to indicate that there is no
value with "fetch.fsck.". This would allow us to properly differentiate
between the "didn't handle the value" and error cases.
I'll send another version making this change and add some comments to
document the behavior.
-Justin
