Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs
- From
David Turner <dturner@twopensource.com>
- Date
- Jul 15, 2015, 18:04 UTC
- Message-ID
- <1436983476.7540.4.camel@twopensource.com>
- In-Reply-To
- <xmqqd1ztxubj.fsf@gitster.dls.corp.google.com>
On Wed, 2015-07-15 at 09:24 -0700, Junio C Hamano wrote:
Show 11 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.
I just did a brief survey here and folks here agree with you. So, I'll adjust my patches accordingly.
Show 10 quoted lines
> > 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.