Re: "git worktree repair" modifies the wrong repository
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Sep 24, 2024, 13:53 UTC
- 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:
Show 14 quoted lines
> 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