git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: "Eric Sunshine" <sunshine@sunshineco.com>,
	"Sean Allred" <allred.sean@gmail.com>,
	"Git List" <git@vger.kernel.org>,
	"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Derrick Stolee" <derrickstolee@github.com>,
	"Taylor Blau" <ttaylorr@github.com>,
	"Elijah Newren" <newren@gmail.com>
Subject: Re: Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository()
Date: Mon, 20 Dec 2021 08:20:26 -0800	[thread overview]
Message-ID: <xmqq5yrjxn79.fsf@gitster.g> (raw)
In-Reply-To: <f39af047-d244-14be-4cd8-b6c3199545f3@gmail.com> (Derrick Stolee's message of "Mon, 20 Dec 2021 09:11:38 -0500")

Derrick Stolee <stolee@gmail.com> writes:

> Thanks for this context of added responsibility. It seems a bit strange
> to require this, since it doesn't make any sense to have a bare worktree
> (at least not to me, feel free to elaborate on the need of such a
> situation).

Stepping back a bit, those who want to have two new worktrees
attached to a single bare repository justify the wish by saying that
neither of these two new worktrees should be the primary thing that
they can lose to make the other inoperable, and having a dedicated
"shared object and ref store" repository makes it more symmetric and
safer by making it obvious which one is the precious thing to keep.

Wanting to create two new "bare repository lookalike" attached to a
single bare repository might be defensible the same way.

Not that the current "git worktree" has readily-available features
to create such a layout.  If people who have worked on "worktree"
did not see the possibility of needing such a layout, it is
understandable that such features wouldn't have been designed yet.

Also not that I think that such a layout necessarily makes sense.

      parent reply	other threads:[~2021-12-20 16:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-18 16:46 Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository() Sean Allred
2021-12-18 17:47 ` rsbecker
2021-12-18 19:00   ` Sean Allred
2021-12-18 21:55     ` rsbecker
2021-12-19 20:16 ` Eric Sunshine
2021-12-19 20:46   ` Sean Allred
2021-12-19 21:32     ` rsbecker
2021-12-19 22:23       ` Sean Allred
2021-12-19 22:51         ` rsbecker
2021-12-19 23:30           ` Eric Sunshine
2021-12-19 23:45             ` Eric Sunshine
2021-12-19 23:54             ` rsbecker
2021-12-20  0:07               ` Eric Sunshine
2021-12-20  0:58     ` Eric Sunshine
2021-12-20 14:11       ` Derrick Stolee
2021-12-20 15:58         ` Eric Sunshine
2021-12-20 17:29           ` Derrick Stolee
2021-12-20 21:58             ` Eric Sunshine
2021-12-20 16:20         ` Junio C Hamano [this message]

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=xmqq5yrjxn79.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=allred.sean@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=pclouds@gmail.com \
    --cc=stolee@gmail.com \
    --cc=sunshine@sunshineco.com \
    --cc=ttaylorr@github.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).