Patrick Steinhardt [off-list ref] writes:

On Mon, Dec 01, 2025 at 12:24:57PM +0100, Karthik Nayak wrote:

quoted

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/ (local)