Michael Haggerty <[email protected]> writes:
> I argue that the fundamental concept in terms of the implementation
> should be the individual physical reference stores, and these should be
> compounded together to form the logical reference collections and the
> sets of reachability roots that are interesting at the UI level.
That is very good in principle. How does that principle translate
to the current setup (with possible enhancement with pluggable ref
backends) and multiple worktrees? Let me try thinking it through
aloud.
* Without pluggable ref backend or worktrees, we start from two
"physical reference stores"; packed-refs file lists refs that
will be covered (overridden) by loose refs in .git/refs/.
Symbolic refs always being in loose falls out as a natural
consequence that packed-refs file does not record symrefs.
* Throw in multiple worktrees to the mix. How? Do we consider
selected refs/ hierarchies (like refs/bisect/*) as separate
physical store (even though it might be backed by the files in
the same .git/refs/ filesystem hierarchy) and represent the
"logical" view as an overlay across the traditional two types of
physical reference stores? That is:
- loose refs in .git/HEAD, .git/refs/{bisect,...} for
per-worktree part form one physical store. If a ref is found
here, that is what we use as a part of the logical view.
- loose refs in .git/refs/{branches,tags,notes,...} for common
part form one physical store. For a ref that is not found
above but is found here becomes a part of the logical view.
- packed refs in .git/packed-refs is another physical store. For
a ref that is not found in the above two but is found here
becomes a part of the logical view.
Up to this point, I am all for your "separate physical stores are
composited to give a logical view". I can see how multi-worktree
world view fits within that framework.
* With pluggable ref backend, we may gain yet another "physical
reference store" possibility, e.g. one backed by lmdb. If it
supports symrefs, a repoitory may use lmdb backed reference store
without the traditional two.
But it is unclear how it would interact with the multi-worktree
world order.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html