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

From: Tao Klerks <tao@klerks.biz>
Date: Sep 4, 2023, 15:29 UTC
Message-ID: <CAPMMpohpKJdopSpZu+ehE0MZrH8cksgtY1NEHFyZz2jj+LOKhA@mail.gmail.com>
In-Reply-To: <CAPMMpoj7s=ewXJfJyxvrcHjpmOOWEWBvZ94OOuVmYs2UQ482HA@mail.gmail.com>

On Mon, Sep 4, 2023 at 4:59 PM Tao Klerks <tao@klerks.biz> wrote:

Show 11 quoted lines

>
>
> It seems, to me, that "my setup" makes a lot more sense than what you
> end up with when you use "--separate-git-dir", and that the behavior
> there predates the current "mutual reference" model of
> worktrees-to-their-repo. If "my" use of "core.bare" in the example
> above is sound - then should the implementation of
> "--separate-git-dir" be changed to produce a bare repo with a
> "worktrees" folder, like you get if you clone bare and add a worktree
> in two separate steps?
>

And to confuse matters further, I just stumbled across
https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir
- I don't understand when you would want to use that vs, again, a bare
repo with one or more worktrees properly attached via two-way
references, their own indexes, their own reflogs, etc.

Is it the case that this contrib script predates the current "git worktree" support?