Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 15, 2015, 16:24 UTC
- Message-ID
- <xmqqd1ztxubj.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <1436848402.5074.21.camel@twopensource.com>
David Turner <dturner@twopensource.com> writes:
Show 7 quoted lines
> 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.
Show 5 quoted lines
> 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?