git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Elijah Newren <newren@gmail.com>, Jeff King <peff@peff.net>
Subject: Re: [PATCH 2/8] Add a place for (not) sharing stuff between worktrees
Date: Tue, 25 Sep 2018 18:55:31 +0200
Message-ID: <CACsJy8BRv1wb7urzriaj9AceZh-Ot1Tsb2w9rExRXkoHFn7_hw@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kZw8-BiW5VE_YN5X2E07FeMA=XtHpjcUoSFtWNRu44fAQ@mail.gmail.com>

On Tue, Sep 25, 2018 at 6:24 PM Stefan Beller <sbeller@google.com> wrote:
> > > That sounds dangerous to me. There is already a concept of
> > > local and remote-tracking branches. So I would think that local
> > > may soon become an overused word, (just like "index" today or
> > > "recursive" to a lesser extend).
> > >
> > > Could this special area be more explicit?
> > > (refs/worktree-local/ ? or after peeking at the docs below
> > > refs/un-common/ ?)
> >
> > refs/un-common sounds really "uncommon" :D. If refs/local is bad, I
> > guess we could go with either refs/worktree-local, refs/worktree,
> > refs/private, refs/per-worktree... My vote is on refs/worktree. I
>
> refs/worktree sounds good to me (I do not object), but I am not
> overly enthused either, as when I think further worktrees and
> submodules are both features with a very similar nature in that
> they touch a lot of core concepts in Git, but seem to be a niche
> feature for the masses for now.

I think the similarity is partly because submodule feature also has to
manage worktrees. My view is at some point, this "git worktree" would
be good enough that it can handle submodules as well (for the worktree
part only of course)

> For example I could think of submodules following this addressing
> mode as well: submodule/<path>/master sounds similar to the
> originally proposed worktree/<name>/<branch> convention.
> For now it is not quite clear to me why you would want to have
> access to the submodule refs in the superproject, but maybe
> the use case will come later.

Yeah. In theory we could "mount" the submodule ref store to a
superproject's ref store. I think it may be needed just for the same
reason it's needed for worktree: error reporting. If you peek into a
submodule and say "HEAD has an error", the user will get confused
whether it's superproject's HEAD or a submodule's HEAD.

> And with that said, I wonder if the "local" part should be feature agnostic,
> or if we want to be "local" for worktrees, "local" for remotes, "local"
> for submodules (i.e. our own refs vs submodule refs).

You lost me here.

>
> > think as long as the word "worktree" is in there, people would notice
> > the difference.
>
> That makes sense. But is refs/worktree shared or local? It's not quite
> obvious to me, as I could have refs/worktree/<worktree-name>/master
> instead when it is shared, so I tend to favor refs/local-worktree/ a bit
> more, but that is more typing. :/

OK I think mixing the two patches will different purposes messes you
(or me) up ;-)

refs/worktrees/xxx (and refs/main/xxx) are about visibility from other
worktrees. Or like Eric put it, they are simply aliases. These refs
are not shared because if they are, you can already see them without
new "ref mount points" like this.

refs/worktree (previously refs/local) is also per-worktree but it's
specifically because you can't have per-worktree inside "refs/" (the
only exception so far is refs/bisect which is hard coded). You can
have refs outside "refs/" (like HEAD or FETCH_HEAD) and they will not
be shared, but they cannot be iterated while those inside refs/ can
be. This is more about deciding what to share and I believe is really
worktree-specific and only matters to _current_ worktree.

Since refs/worktree is per-worktree, you can also view them from a
different worktree via refs/worktrees/. E.g. if you have
refs/worktree/foo then another worktree can see it via
refs/worktrees/xxx/refs/worktree/foo (besides pseudo refs like
refs/worktrees/xxx/HEAD)

> As we grow the worktree feature, do we ever expect the need to
> reference the current worktree?
>
> For example when there is a ref "test" that could be unique per
> repo and in the common area, so refs/heads/test would describe
> it and "test" would get there in DWIM mode.
>
> But then I could also delete the common ref and recreate a "test"
> ref in worktree A, in worktree B however DWIMming "test" could still
> refer to A's "test" as it is unique (so far) in the repository.
> And maybe I would want to check if test exists locally, so I'd
> want to ask for "self/test" (with "self" == "B" as that is my cwd).

You probably lost me again. In theory we must be able to detect
ambiguity and stop DWIMing. If you want to be ambiguity-free, you
specify full ref name, starting with "refs/" which should function
like "self/" because worktree design so far is always about the
current worktree's view.
-- 
Duy

  reply index

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-22 18:04 [PATCH 0/8] fix per-worktree ref iteration in fsck/reflog expire Nguyễn Thái Ngọc Duy
2018-09-22 18:04 ` [PATCH 1/8] refs.c: indent with tabs, not spaces Nguyễn Thái Ngọc Duy
2018-09-22 18:04 ` [PATCH 2/8] Add a place for (not) sharing stuff between worktrees Nguyễn Thái Ngọc Duy
2018-09-23  7:51   ` Eric Sunshine
2018-09-25  2:35   ` Stefan Beller
2018-09-25 15:36     ` Duy Nguyen
2018-09-25 16:24       ` Stefan Beller
2018-09-25 16:55         ` Duy Nguyen [this message]
2018-09-25 17:56           ` Stefan Beller
2018-09-22 18:04 ` [PATCH 3/8] refs: new ref types to make per-worktree refs visible to all worktrees Nguyễn Thái Ngọc Duy
2018-09-23  8:06   ` Eric Sunshine
2018-09-23 13:10     ` Duy Nguyen
2018-09-25  2:48   ` Stefan Beller
2018-09-25 15:49     ` Duy Nguyen
2018-09-25 16:53       ` Stefan Beller
2018-09-25 21:16   ` Junio C Hamano
2018-09-29 18:26     ` Duy Nguyen
2018-10-06 23:20       ` Junio C Hamano
2018-09-22 18:04 ` [PATCH 4/8] revision.c: correct a parameter name Nguyễn Thái Ngọc Duy
2018-09-22 18:04 ` [PATCH 5/8] revision.c: better error reporting on ref from different worktrees Nguyễn Thái Ngọc Duy
2018-09-23  8:25   ` Eric Sunshine
2018-09-23 13:15     ` Duy Nguyen
2018-09-22 18:04 ` [PATCH 6/8] fsck: Move fsck_head_link() to get_default_heads() to avoid some globals Nguyễn Thái Ngọc Duy
2018-09-22 18:04 ` [PATCH 7/8] fsck: check HEAD and reflog from other worktrees Nguyễn Thái Ngọc Duy
2018-09-23  8:41   ` Eric Sunshine
2018-09-29 18:40     ` Duy Nguyen
2018-09-22 18:05 ` [PATCH 8/8] reflog expire: cover reflog from all worktrees Nguyễn Thái Ngọc Duy
2018-09-29 19:10 ` [PATCH v2 0/8] fix per-worktree ref iteration in fsck/reflog expire Nguyễn Thái Ngọc Duy
2018-09-29 19:10   ` [PATCH v2 1/8] refs.c: indent with tabs, not spaces Nguyễn Thái Ngọc Duy
2018-09-29 19:10   ` [PATCH v2 2/8] Add a place for (not) sharing stuff between worktrees Nguyễn Thái Ngọc Duy
2018-09-29 19:10   ` [PATCH v2 3/8] refs: new ref types to make per-worktree refs visible to all worktrees Nguyễn Thái Ngọc Duy
2018-09-30  5:13     ` Eric Sunshine
2018-10-07  1:37     ` Junio C Hamano
2018-09-29 19:10   ` [PATCH v2 4/8] revision.c: correct a parameter name Nguyễn Thái Ngọc Duy
2018-09-29 19:10   ` [PATCH v2 5/8] revision.c: better error reporting on ref from different worktrees Nguyễn Thái Ngọc Duy
2018-09-30  5:25     ` Eric Sunshine
2018-09-29 19:10   ` [PATCH v2 6/8] fsck: Move fsck_head_link() to get_default_heads() to avoid some globals Nguyễn Thái Ngọc Duy
2018-09-29 19:10   ` [PATCH v2 7/8] fsck: check HEAD and reflog from other worktrees Nguyễn Thái Ngọc Duy
2018-09-29 19:10   ` [PATCH v2 8/8] reflog expire: cover reflog from all worktrees Nguyễn Thái Ngọc Duy
2018-09-30  5:36     ` Eric Sunshine
2018-10-02 16:16       ` Duy Nguyen
2018-10-03  7:49         ` Eric Sunshine
2018-10-21  8:08   ` [PATCH v3 0/8] fix per-worktree ref iteration in fsck/reflog expire Nguyễn Thái Ngọc Duy
2018-10-21  8:08     ` [PATCH v3 1/8] refs.c: indent with tabs, not spaces Nguyễn Thái Ngọc Duy
2018-10-21  8:08     ` [PATCH v3 2/8] Add a place for (not) sharing stuff between worktrees Nguyễn Thái Ngọc Duy
2018-10-22  4:28       ` Junio C Hamano
2018-10-29 17:18         ` Duy Nguyen
2018-10-22 10:25       ` SZEDER Gábor
2018-10-21  8:08     ` [PATCH v3 3/8] refs: new ref types to make per-worktree refs visible to all worktrees Nguyễn Thái Ngọc Duy
2018-11-24 19:27       ` Ævar Arnfjörð Bjarmason
2018-11-25  1:19         ` Junio C Hamano
2018-11-25  4:58         ` [PATCH] files-backend.c: fix build error on Solaris Nguyễn Thái Ngọc Duy
2018-11-25 10:19           ` Carlo Arenas
2018-11-25 10:40             ` Duy Nguyen
2018-11-26  4:44             ` Junio C Hamano
2018-10-21  8:08     ` [PATCH v3 4/8] revision.c: correct a parameter name Nguyễn Thái Ngọc Duy
2018-10-21  8:08     ` [PATCH v3 5/8] revision.c: better error reporting on ref from different worktrees Nguyễn Thái Ngọc Duy
2018-10-21  8:08     ` [PATCH v3 6/8] fsck: Move fsck_head_link() to get_default_heads() to avoid some globals Nguyễn Thái Ngọc Duy
2018-10-21  8:08     ` [PATCH v3 7/8] fsck: check HEAD and reflog from other worktrees Nguyễn Thái Ngọc Duy
2018-10-21  8:08     ` [PATCH v3 8/8] reflog expire: cover reflog from all worktrees Nguyễn Thái Ngọc Duy

Reply instructions:

You may reply publically 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CACsJy8BRv1wb7urzriaj9AceZh-Ot1Tsb2w9rExRXkoHFn7_hw@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=sbeller@google.com \
    /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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox