Re: "git worktree repair" modifies the wrong repository

> On Tue, Sep 24, 2024 at 9:53 AM Phillip Wood <phillip.wood123@gmail.com> wrote:
>> 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.
> 
> Thanks, Phillip. This is interesting information, but I'm not sure I
> understand what the actual problems are that you encountered. When you
> say that --bare implies --mirror, do you mean the other way around?
> The documentation states the opposite; that --mirror implies --bare,
> and my own testing seems to confirm that.

> That aside, I played around a bit again with bare and mirror
> repositories with worktrees hanging off them, but didn't encounter any
> anomalous behavior, which (almost certainly) indicates that I'm not
> exercising it thoroughly enough. Thus, can you provide more detail
> about the actual problems you encountered which required the manual
> adjustments you made to the configuration? (Does this also imply that
> Documentation/git-worktree.txt could use an update to discuss how to
> use them with a bare repository?)

> Regarding core.bare: That's one of the settings which is special-cased
> (hard-coded) to work "properly" when extensions.worktreeConfig is not
> enabled, so it's not clear what problem you were experiencing in that
> regard. In my testing, `git rev-parse --is-bare-repository` correctly
> reported "true" in the bare repository, and "false" in a worktree
> hanging off the bare repository even when extensions.worktreeConfig
> was not enabled.