From: Phillip Wood <phillip.wood123@gmail.com>
Date: Tue, 24 Sep 2024 13:53:44 GMT
Subject: Re: "git worktree repair" modifies the wrong repository
Message-ID: <87afa860-52f4-414a-82da-09e7eeac1301@gmail.com>
In-Reply-To: <CAPig+cTop=2+k0XbqYbsCTbJVo77evY+_a+FqDV_ziKf2q+Dzw@mail.gmail.com>

On 23/09/2024 19:52, Eric Sunshine wrote:
> On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart
> <russell+git.vger.kernel.org@stuart.id.au> wrote:
>> Interestingly, people (including me as it happens) start out by trying
>> to emulate the hg approach using a single parent directory to hold a
>> bare repository, and the child worktree directories.  Then they discover
>> bare repositories mangle the remote links, and give up on the idea.
> 
> Can you provide more details about this "mangling"? Although the
> use-case you describe was not directly considered in the initial
> design, worktrees hanging off a bare repository became an
> explicitly-supported use-case not long after worktrees were
> introduced. So, it should work properly and we know that people use
> worktrees this way, but we haven't had any reports of mangling in this
> scenario.

I can't speak for Russell but a while ago when I added a worktree to an 
existing bare repository I had to update remote.origin.fetch and 
remote.origin.mirror because "git clone --bare" implies "--mirror". I 
also needed to enable extensions.worktreeConfig and ensure core.bare was 
set appropriately.

Best Wishes

Phillip