Hi Eric
On 03/10/2024 07:28, Eric Sunshine wrote:
On Tue, Sep 24, 2024 at 9:53 AM Phillip Wood <phillip.wood123@xxxxxxxxx> 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@xxxxxxxxxxxx> 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
