Re: [PATCH v4 5/5] Reftable support for git-core

>
> On 2020-02-06 at 22:55:56, Han-Wen Nienhuys via GitGitGadget wrote:
> > @@ -403,6 +417,10 @@ int init_db(const char *git_dir, const char *real_git_dir,
> >               git_config_set("receive.denyNonFastforwards", "true");
> >       }
> >
> > +     if (flags & INIT_DB_REFTABLE) {
> > +             git_config_set("extensions.refStorage", "reftable");
> > +     }
>
> This does seem like the best way to do this.  Can we get an addition to
> Documentation/technical/repository-version.txt that documents this
> extension and the values it takes?  I presume "reftable" and "files" are
> options, but it would be nice it folks didn't have to dig through the
> code to find that out.

> I wonder if this might be better as --refs-backend={files|reftable}.  If
> reftable becomes the default at some point in the future, it would be
> easier to let people explicitly specify that they want a non-reftable
> version.  If we learn support for a hypothetical reftable v2 in the
> future, maybe we'd want to let folks specify that instead.

> > -static struct ref_storage_be *refs_backends = &refs_be_files;
> > +static struct ref_storage_be *refs_backends = &refs_be_reftable;
>
> I'm not sure why we're making this change.  It doesn't look like the
> default is changing.

>
> > @@ -1913,7 +1916,7 @@ struct ref_store *get_submodule_ref_store(const char *submodule)
> >               goto done;
> >
> >       /* assume that add_submodule_odb() has been called */
> > -     refs = ref_store_init(submodule_sb.buf,
> > +     refs = ref_store_init(submodule_sb.buf, "files", /* XXX */
> >                             REF_STORE_READ | REF_STORE_ODB);
> >       register_ref_store_map(&submodule_ref_stores, "submodule",
> >                              refs, submodule);
> > @@ -1927,6 +1930,7 @@ struct ref_store *get_submodule_ref_store(const char *submodule)
> >
> >  struct ref_store *get_worktree_ref_store(const struct worktree *wt)
> >  {
> > +     const char *format = "files"; /* XXX */
>
> If the question is whether we still want to default to "files" as the
> default, then yes, I think we do.  Suddenly changing things would be a
> problem if for some reason someone needed to downgrade Git versions.
>
> Since we have two instances of "files" above, it might be better to
> create a #define like DEFAULT_REF_BACKEND or some such.