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