Re: [PATCH 1/2] refs: support obtaining ref_store for given dir
- From
Karthik Nayak <karthik.188@gmail.com>
- Date
- Nov 21, 2025, 11:18 UTC
- Message-ID
- <CAOLa=ZTeadFsZNNxjObwrS_a4kTC3V3d6ubn=DXncEzzvWe2MQ@mail.gmail.com>
- In-Reply-To
- <pyt5nc2v25oarqmuxld4nrknmsomjnyooj25ffjetcue5zq7xi@vglcil42as5a>
Justin Tobler <jltobler@gmail.com> writes:
Show 17 quoted lines
> On 25/11/19 10:48PM, Karthik Nayak wrote: >> The refs subsystem uses the `get_main_ref_store()` to obtain the main >> ref_store for a given repository. In the upcoming patches we also want >> to create a ref_store for any given reference directory, which may exist >> in arbitrary paths. To support such behavior, extract out the core logic >> for creating out the ref_store from `get_main_ref_store()` into a new >> function `get_ref_store_for_dir()` which can provide the ref_store for a >> given (repository, directory, reference format) combination. > > So when we refer to the "reference directory" in this case, we are not > refering to the "refs/" or "reftable/" directories directly, but one > level above that which is typically just the gitdir itself. This seems a > bit awkward at first, but makes sense since, for the files backend, > there may be symbolic references such as HEAD that exist outside of > "refs/" which must be considered. It might be helpful to clarify this in > the commit message. >
You're right, for the files and the reftable backend, this happens to be the $GIT_DIR itself, due to how closely they are integrated with Git. But if you build an external reference backend, this doesn't have to be the $GIT_DIR.
I've modified the commit message accordingly
> Otherwise this patch looks good. > > -Justin