Re: The design of refs backends, linked worktrees and submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 19, 2017, 19:44 UTC
Message-ID: <xmqq8tq625ti.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CACsJy8CHoroX2k9GqOFmXkvvPCPN4SBeCg+6aC2WSWNSKVmWQw@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

> ... A bit worried about transactions though,
> because I think per-repo and per-worktree updates will be separated in
> two transactions. But that's probably ok because future backends, like
> lmdb, will have to go through the same route anyway.

If we have per-worktree ref-store, what can be done as a useful thing by future backends like lmdb may be to use the same single database to store shared and per-worktree refs, similar to the way Michael mentioned in his response to your message I am responding to, i.e.

    I kindof think that it would have been a better design to store the
    references for all linked worktrees in the main repository's ref-store.
    For example, the "bisect" refs for a worktree named "<name>" could have
    been stored under "refs/worktrees/<name>/bisect/*".

The current design is heavily influenced by how "contrib/workdir" lays things out, for the latter of which I take the blame X-<, but perhaps the files backend can be retrofitted to use that layout in the longer term?