All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: David Turner <dturner@twopensource.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>, git@vger.kernel.org
Subject: Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs
Date: Wed, 15 Jul 2015 09:24:32 -0700	[thread overview]
Message-ID: <xmqqd1ztxubj.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1436848402.5074.21.camel@twopensource.com> (David Turner's message of "Tue, 14 Jul 2015 00:33:22 -0400")

David Turner <dturner@twopensource.com> 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?

  reply	other threads:[~2015-07-15 16:24 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08  0:55 [PATCH v7 1/8] refs.c: add err arguments to reflog functions David Turner
2015-07-08  0:55 ` [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs David Turner
2015-07-08 17:46   ` Johannes Sixt
2015-07-08 19:16     ` David Turner
2015-07-08 21:14       ` Johannes Sixt
2015-07-08 23:23         ` Junio C Hamano
2015-07-08 23:44           ` David Turner
2015-07-09  5:55             ` Junio C Hamano
2015-07-09 21:53               ` David Turner
2015-07-09 22:06                 ` Junio C Hamano
2015-07-10  4:30                   ` Michael Haggerty
2015-07-10 17:59                     ` David Turner
2015-07-14  4:33                     ` David Turner
2015-07-15 16:24                       ` Junio C Hamano [this message]
2015-07-15 18:04                         ` David Turner
2015-07-08 23:41         ` David Turner
2015-07-08  0:55 ` [PATCH v7 3/8] bisect: treat BISECT_HEAD as a ref David Turner
2015-07-08  0:55 ` [PATCH v7 4/8] refs: Break out check for reflog autocreation David Turner
2015-07-08  0:56 ` [PATCH v7 5/8] refs: new public ref function: safe_create_reflog David Turner
2015-07-08 11:49   ` Michael Haggerty
2015-07-08  0:56 ` [PATCH v7 6/8] git-reflog: add exists command David Turner
2015-07-08  0:56 ` [PATCH v7 7/8] update-ref and tag: add --create-reflog arg David Turner
2015-07-08 13:44   ` Michael Haggerty
2015-07-08 20:21     ` David Turner
2015-07-08  0:56 ` [PATCH v7 8/8] git-stash: use update-ref --create-reflog instead of creating files David Turner
2015-07-08  7:28   ` Junio C Hamano
2015-07-08  7:33   ` Junio C Hamano
2015-07-08 13:50   ` Michael Haggerty
2015-07-08 11:36 ` [PATCH v7 1/8] refs.c: add err arguments to reflog functions Michael Haggerty
2015-07-08 20:01   ` David Turner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqd1ztxubj.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.