Re: [PATCH 0/2] refs: allow setting the reference directory

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 23, 2025, 04:29 UTC
Message-ID: <xmqq34651ie5.fsf@gitster.g>
In-Reply-To: <20251119-kn-alternate-ref-dir-v1-0-4cf4a94c8bed@gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

> While Git allows users to select different reference backends, unlike
> with objects, there is no flexibility in selecting the reference
> directory. Currently, the reference format is obtained from the config
> of the repository and the reference directory is set to the $GIT_DIR.

I actually am not sure if I like the proposed environment variable.

The proposal is based on an assumption that any reference backend should be able to move their backing store anywhere, and they should be able to express the location of their backing store as a single string <path>. For a new backend, "where is your backing store" may not even be a question that does not make much sense (as "somewhere in the cloud that you do not even have to know" is certainly possible), and even for a new backend design that does allow such a question to have a meaningful answer, this "you have to be able to use a random place specified by this environment variable as your backing storage" is an additional requirement that its implementors may not need to satisfy in order to please their user base.

For reftable and files backends, these assumptions may be true, but then it is not too cumbersome if these stay to be backend specific, as there are only two backends.

So I dunno. In addition, if this is designed to help migration (which is the impression I am getting from the cover letter description), don't you need a way to specify more than one (i.e., source to migrate from and destination to migrate to)? With a single GIT_REF_URI, it would not be obvious what it refers to, whether it is an additional place to write to, to read from, or something completely unrelated. For example ...

Show 17 quoted lines

> This patch series adds a new ENV variable 'GIT_REF_URI' which takes the
> reference backend and path in a URI form:
>
>     <reference_backend>://<path>
>
> For e.g. 'reftable:///foo' or 'files://$GIT_DIR/ref_migration.0xBsa0'.
>
> One use case for this is migration between different backends. On the
> server side, migrating from the files backend to the newly introduced
> reftable backend can be achieved by running 'git refs migrate'. However,
> for large repositories with millions of references, this migration can
> take from seconds to minutes.
>
> We could make the migration non-blocking by running the migration in the
> background and capturing and replaying updates to both backends. This
> would require Git to support writing references to different reference
> backends and paths.

... I am reading that the above is saying that the system will write to whatever reference backend specified in the extension.refStorage, plus also where GIT_REF_URI points at, but if that is the way how the mechanism works, the variable should be named more specific to what it does, no? It is not just a random "REF URI"; it is an additional ref backend that the updates are dumped to. Maybe there would be a different use case where you may want to read from two reference backends, and you'd need to specify the secondary one with an environment variable, but if the system behaves one specific way for GIT_REF_URI (say, all updates are also copied to this additional ref backend at the specified ref backing store), a different environment variable name needs to be chosen to serve such a different use case, no?