Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: >> All correct. The per-worktree part of the repository data does live >> in a subdirectory of the ".git" directory and that was probably what >> Tao had in mind, though. > > That could be. I read Tao's explanation as meaning that people do this: > > git clone foo.git foo > cd foo > git worktree add bar > git worktree add baz > > rather than (perhaps) this: > > git clone foo.git foo > cd foo > git worktree add ../bar > git worktree add ../baz Ah, that reading does totally make sense. But I am not sure it would lead to "we need to carefully protect the primary worktree", because it is rather obvious, especially if you bypass "git worktree remove" and use "rm -fr", you would lose everybody underneath if you remove the "foo" in the "worktrees are subdirectories of the primary" variant in the above examples. Even though deriving the worktree(s) from a separate and protected bare repositories does protect you from total disaster caused by removing "rm -fr" and bypassing "git worktree remove", it still should be discouraged, as the per-worktree states left behind in the repository interfere with the operations in surviving worktrees. Teaching folks not to do "rm -fr" would be the first step to a more pleasant end-user experience, I would think. Thanks.