Re: Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository()

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 20, 2021, 16:20 UTC
Message-ID: <xmqq5yrjxn79.fsf@gitster.g>
In-Reply-To: <f39af047-d244-14be-4cd8-b6c3199545f3@gmail.com>

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.