From: phillip.wood123@gmail.com
Date: Fri, 04 Oct 2024 09:15:55 GMT
Subject: Re: "git worktree repair" modifies the wrong repository
Message-ID: <6c0b8681-95ca-4224-ba89-7582fd731565@gmail.com>
In-Reply-To: <CAPig+cSSDnq_kh9ERuYZmUCNrVvWmGFF8OSfBCy8bHrkx6fz3g@mail.gmail.com>

Hi Eric

On 03/10/2024 07:28, Eric Sunshine wrote:
> 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.

Sorry I must have mis-remembered - it was quite a while ago. In my case 
the bare repository was set up with --mirror.

> 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?)

"git clone --mirror" sets up a fetch refspec that forcibly update 
"refs/heads/*" when fetching. This means fetching overwrites your local 
branches and I think the fetch fails if you have a branch checked out 
that it wants to update. "git clone --bare" does not set up any fetch 
refspec. In both cases there are no remote tracking branches to base 
your local work on.

> 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.

I've a feeling I thought I needed to set it because I didn't realize 
that core.bare was special cased rather than doing so in response to a 
particular problem but I can't remember for sure.

Best Wishes

Phillip