Re: Is "bare"ness in the context of multiple worktrees weird? Bitmap error in git gc.

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2023, 15:13 UTC
Message-ID: <xmqqmsy0slei.fsf@gitster.g>
In-Reply-To: <CAPig+cRJhrGmnBRm2dporcXiRr4SzRmpM2LTMm0S7wo0XbOU9Q@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 17 quoted lines

>> All correct.  The per-worktree part of the repository data does live
>> in a subdirectory of the ".git" directory and that was probably what
>> Tao had in mind, though.
>
> That could be. I read Tao's explanation as meaning that people do this:
>
>     git clone foo.git foo
>     cd foo
>     git worktree add bar
>     git worktree add baz
>
> rather than (perhaps) this:
>
>     git clone foo.git foo
>     cd foo
>     git worktree add ../bar
>     git worktree add ../baz

Ah, that reading does totally make sense.

But I am not sure it would lead to "we need to carefully protect the primary worktree", because it is rather obvious, especially if you bypass "git worktree remove" and use "rm -fr", you would lose everybody underneath if you remove the "foo" in the "worktrees are subdirectories of the primary" variant in the above examples.

Even though deriving the worktree(s) from a separate and protected bare repositories does protect you from total disaster caused by removing "rm -fr" and bypassing "git worktree remove", it still should be discouraged, as the per-worktree states left behind in the repository interfere with the operations in surviving worktrees. Teaching folks not to do "rm -fr" would be the first step to a more pleasant end-user experience, I would think.

Thanks.