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

From: Karthik Nayak <karthik.188@gmail.com>
Date: Jan 5, 2026, 20:13 UTC
Message-ID: <CAOLa=ZT5YwDXEs=wHqVcHqLNxen51-hucaPXOWQEMug3oWfxOA@mail.gmail.com>
In-Reply-To: <aVvVAH1eRxGa60Fp@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 32 quoted lines

> On Mon, Dec 01, 2025 at 12:24:57PM +0100, Karthik Nayak wrote:
>> Changes in v3:
>> - Cleanup some stale code which wasn't removed.
>> - Localize strings which will be output to the user.
>> - Remove additional defensive checks which are not needed.
>> - Link to v2: https://patch.msgid.link/20251126-kn-alternate-ref-dir-v2-0-8b9f6f18f635@gmail.com
>
> FYI: I did an internal review of this at [1] and mentioned a couple of
> things that I think still need to be iterated on. Most importantly, I
> think that we also need to handle worktrees:
>
>     I think we need to do something about worktree ref stores in the
>     context of this series, as we're now thinking a bit broader than
>     before. It would be somewhat weird if you can change the main
>     reference store, but it doesn't have any influence on the worktree
>     ref stores. If I say e.g. that the ref store is located in
>     `/tmp/dir`, then I'd expect that the main ref store would be in
>     `/tmp/dir/refs` and that worktree refs are in
>     `/tmp/dir/worktrees/$name/refs`.
>
>     The reason I think this needs to be handled as part of this MR is
>     that we are extending semantics of the extension now. This is only
>     possible because the extensions are quite strict now, and thus we
>     can strictly extend them. But once we have extended them we cannot
>     just alter their semantics to also cover worktree refs.
>
> So you can expect another iteration of this patch series once folks
> settle into their usual post-holiday rhythms again :)
>
> Patrick
>
> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/451

Thanks for putting that here. I did reply to one of Junio's what's cooking emails [1] stating the same (mostly that I'm on vacation) and that the topic isn't abandoned but would be delayed.

I've been looking at this with a fresh set of eyes post vacation. One of the things I still need to solve is around how this works with Git directory detection.

The current implementation works because it hijacks the refs initialization to set the new reference directory. But this assumes that the repository has a 'refs/' folder and 'HEAD' file within the $GITDIR.

So if we want this to work with worktrees the way that Patrick mentioned, we'd have to create the worktree reference path within the provided reference storage path. But this would mean that the $GITDIR for the worktree wouldn't be initialized with the required files currently required for being a valid Git directory.

The issue is that config parsing is only done post Git directory detection. One hacky fix is to create a dummy 'refs/' folder and 'HEAD' file within the $GITDIR, similar to how the 'reftable does it. I'm not a big fan of adding something like that. Would be curious if anyone has further thoughts on this.

[1]: https://lore.kernel.org/git/CAOLa=ZTeEEntiQdCnDd6B8a_ppJrrZqdURhQJV=bNktnp0JqMw@mail.gmail.com/