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

David Turner [off-list ref] 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?

On Wed, 2015-07-15 at 09:24 -0700, Junio C Hamano wrote:

quoted

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.

I just did a brief survey here and folks here agree with you.  So, I'll
adjust my patches accordingly.

quoted

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?

That sounds good to me, but judging by the docs, that's not yet
implemented.  So I'm going to worry about that when it is implemented.