On Mon, Sep 4, 2023 at 1:57 PM Kristoffer Haugsbakk <code@xxxxxxxxxxxxxxx> wrote: > On Mon, Sep 4, 2023, at 16:41, Tao Klerks wrote: > > Because worktree use was so useful/widespread/critical on this project, > > and we already had a custom cloning process that introduced selective > > refspecs etc, we introduced a special clone topology: the initial clone > > is a bare repo, and that folder gets a specific clear name (ending in > > .git). Then we create worktrees attached to that bare repo. > > This is interesting as a Git user. I've been encountering questions on > StackOverflow where the questioner is using a bare repository which they > make (or try to make) worktrees from. I've been telling them that making > worktrees from a bare repository is a contradiction:[1] Not at all. The combination of bare repository and multiple-worktrees is legitimate and supported intentionally. (There are tests in the Git test suite validating support of this feature.) For people who regularly work with multiple worktrees, it is quite natural to have all the worktrees hanging off a bare repository, each with equal importance, rather than having a single "blessed" worktree which has priority over all others. > > Bare repositories don’t have worktrees per definition. Or at least > > that’s what `man gitglossary says`. Of course what `git worktree` allows > > you to do trumps that. But it might be ill-defined. > > The glossary says under “worktree” (on Git 2.42): > > > A repository can have zero (i.e. bare repository) or one or more > > worktrees attached to it. Speaking as a person involved in the implementation of worktrees, including support for them in combination with bare repositories, my reading of this is perhaps biased so that I understand its intent. However, if I squint hard, I suppose I can see how you could read it as meaning that a bare repository can't have any worktrees associated with it. So, perhaps, the documentation could use a bit of touch up.
