On Tue, Sep 24, 2024 at 9:53 AM Phillip Wood [off-list ref] wrote:

On 23/09/2024 19:52, Eric Sunshine wrote:

quoted

On Thu, Sep 19, 2024 at 7:40 AM Russell Stuart
[off-list ref] wrote:

quoted

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.