On Fri, Feb 26, 2016 at 10:56:34PM -0500, Jeff King wrote:
> My second confusion is why this is happening in git_config_early(). That
> function is called during the setup of check_repository_format_gently(),
> which is why I think you wanted to put the code here. But it's _also_
> called as part of a regular git_config(). Which means we're parsing the
> repo config and setting the ref backend all over again, every time we
> look at config for other reasons.
>
> So I think this setup probably should be in
> check_repository_format_gently(), and should be able to trigger off of
> the existing ref_storage_backend string we've already saved (and we
> should bail immediately there if we don't know about the backend, as it
> means we _don't_ match the repo's extensions and cannot proceed).
By the way, I notice that the default value for the_refs_backend is
"&refs_be_files". It might be safer to make this NULL (or some
&refs_be_null that fills the vtable, but just returns an error for each
call).
Then in check_repository_format_gently(), do:
if (!ref_storage_backend || !*ref_storage_backend)
refs_backend_storage = "files";
set_ref_storage_backend(ref_storage_backend);
That way you could be sure that the backend has been initialized from
the config, and never blindly falls back to the "files" backend. If
there is any code path where we try to access refs but the_refs_backend
is null, that's a bug that needs fixing. But it's a lot easier to find
such bugs if we die loudly in that case rather than silently using
"files".
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
