On Mon, Sep 4, 2023 at 4:41 PM Tao Klerks <tao@xxxxxxxxxx> wrote: > > 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. > > Generally speaking, this has worked *very* well: I would recommend it > generally as a recognized/supported local-repo-setup. The most > important thing that makes this *possible* is the fact that "git > rev-parse --is-bare-repository" returns True in the bare repo folder, > where the lack of index and HEAD shouldn't bother git, and it returns > False in any one of the worktrees. It feels like things were designed > to work this way, even though I can find no explicit mention of this > topology in the docs. I should add that I only recently discovered "git clone --separate-git-dir", which I at first though was a formal expression of this setup... until I understood that the relationship between the "GITDIR" and the worktree that you end up with is not "Bare repo vs worktree", but rather... "orphaned repo / repo that doesn't know about its worktree, vs worktree". It seems, to me, that "my setup" makes a lot more sense than what you end up with when you use "--separate-git-dir", and that the behavior there predates the current "mutual reference" model of worktrees-to-their-repo. If "my" use of "core.bare" in the example above is sound - then should the implementation of "--separate-git-dir" be changed to produce a bare repo with a "worktrees" folder, like you get if you clone bare and add a worktree in two separate steps? (I say "change the implementation", but I guess I really mean introducing a new option for the new behavior, and deprecate the old option) Dscho, I assume you would have the strongest opinion about this?
