From: Karthik Nayak Date: Tue, 10 Feb 2026 13:02:10 GMT Subject: Re: [PATCH v5 3/4] refs: allow reference location in refstorage config Message-ID: In-Reply-To: Patrick Steinhardt writes: > On Mon, Feb 09, 2026 at 04:58:20PM +0100, Karthik Nayak wrote: >> The 'extensions.refStorage' config is used to specify the reference >> backend for a given repository. Both the 'files' and 'reftable' backends >> utilize the $GIT_DIR as the reference folder by default in >> `get_main_ref_store()`. >> >> Since the reference backends are pluggable, this means that they could >> work with out-of-tree reference directories too. Extend the 'refStorage' >> config to also support taking an URI input, where users can specify the >> reference backend and the location. >> >> Add the required changes to obtain and propagate this value to the >> individual backends also add the necessary documentation and tests. > > This reads as if this should have been two sentences. Yeah, let me split it up. > >> diff --git a/builtin/worktree.c b/builtin/worktree.c >> index fbdaf2eb2e..94480be5c4 100644 >> --- a/builtin/worktree.c >> +++ b/builtin/worktree.c >> @@ -425,6 +425,39 @@ static int make_worktree_orphan(const char * ref, const struct add_opts *opts, >> return run_command(&cp); >> } >> >> +/* >> + * References for worktress are generally stored in '$GIT_DIR/worktrees/'. > > s/worktress/worktrees/ > Oops. >> +for to_format in $ref_formats >> +do >> + if test "$from_format" = "$to_format" >> + then >> + continue >> + fi >> + >> + >> + for dir in "$(pwd)/repo/.git" "./" > > As "./" is a relative directory I expect it to be resolved relative to > "$GIT_DIR", right? Yup the './' is relative to the '$GIT_DIR'. It can be changed to '.', so I'll do that and add a comment. So we do both BACKEND_PATH='/home/karthik/code/git/build/test-output/trash directory.t1423-ref-backend/repo/.git/ref_migration.ZnKNpg' and BACKEND_PATH=./ref_migration.BFyK5k > Also, I don't see any tests that create the ref > directory outside of the repository. Should we maybe add one? Yeah, let me add that test. >> + do >> + >> + test_expect_success "$read from $to_format backend, $dir dir" ' >> + test_when_finished "rm -rf repo" && >> + git init --ref-format=$from_format repo && >> + ( >> + cd repo && >> + test_commit 1 && >> + test_commit 2 && >> + test_commit 3 && >> + >> + git refs migrate --dry-run --ref-format=$to_format >out && > > Okay, we do the migration, but with "--dry-run". This should result in a > temporary staging directory, which is in fact somewhat interesting given > that "to_format" can now contain a payload. I assume it wouldn't have an > impact if such a payload was set here? > It cannot, the 'git refs migrate' command parses the argument provided to '--ref-format' as a reference-backend. >> + BACKEND_PATH="$dir/$(sed "s/.* ${SQ}.git\/\(.*\)${SQ}/\1/" out)" && > > Hm. I have no idea what this is doing :) > It extracts out the name of the dry-run folder created by 'git refs migrate'. We append the $dir to it, which could be the absolute path or the relative path. >> + test_refs_backend . $from_format "$to_format://$BACKEND_PATH" "$method" >> + ) >> + ' > > In general I think it would be sensible to also have a couple tests here > that exercise specific formats directly. Like: > > - Are the files created in the right spots for the files and reftable > backend with a specific backend? > > - Does `git refs migrate` know to write the files into the correct > location in case "--dry-run" wasn't passed? > Will add tests for the following too. > - Does git-init(1) and git-clone(1) initialize the refstore in a > different location as expected? > Well so this only works when there is a reference store already existing. I thought I had explicitly called this out, but doesn't seem to be the case. I think it would actually make sense that it also works with creation. So let me look into that. > - Does creating a worktree work? > This is currently already tested. > Patrick