Subject: Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs

From: Junio C Hamano <[email-masked]>
Date: Wed, 15 Jul 2015 09:24:32 -0700

David Turner <[email-masked]> writes:

> So I am thinking instead that backends should be required to manage
> updates to HEAD themselves, and that some functions from refs-be-files
> would be made generic to help with this.  
> ...
> For the LMDB backend, I could put most of that code at the LMDB access
> ...
> backend, it should still be possible to handle this cleanly.

Sounds sensible.

> On reflection, I think that this would also be a reasonable approach to
> take for stash, which does not fall into any of the listed categories.
> It's not a pseudoref because it's not all-caps and it starts with refs/.
> Unlike other pseudorefs, it needs a reflog.  But like HEAD and unlike
> other refs, it (and its reflog) wants to be per-worktree.

I think we want stash, unlike HEAD, to be shared across worktrees,
and contrib/workdir gets this right.

So there is nothing that makes refs/stash like CHERRY_PICK_HEAD at
all.

> Are there
> other ref-like-things in this category (which I'll call "per-worktree
> refs")?  I guess one set of these is submodules' HEADs.

I've been assuming that a secondary worktree of superproject will
get its own & corresponding secondary worktree of a submodule, which
would automatically give per-worktree "submodule's HEADs" and
everything else that has to be per-worktree.  Am I missing something
or are there any more need for underlying machinery than what we
currently have for secondary worktrees for a single project tree?