Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > This is not accurate. There is no default location for new worktrees; > git-worktree creates the new worktree at the location specified by the > user: > > git worktree add [<options>] <path> [<commit>] > > where <path> -- the only mandatory argument -- specifies the location. 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. > It indeed was designed to work this way. It is perfectly legitimate to > create worktrees attached to a bare repository[1]. > > [1]: Support for bare repositories in conjunction with multiple- > worktrees, however, came after the initial implementation of multiple- > worktrees. An unfortunate side-effect is that established terminology > became somewhat confusing. In particular, in a bare repository > scenario, the term "main worktree" refers to the bare repository, not > to the "blessed" worktree containing the ".git/" directory (since > there is no such worktree in this case). Again all correct. >> Is it the case that this contrib script predates the current "git >> worktree" support? > > git-new-workdir predates git-worktree by quite a few years and, as I > understand it, remains in-tree because it fills a niche not entirely > filled by git-worktree. I actually think there is no longer a valid workflow whose support by "worktree" is still insufficient and the script has outlived its usefulness. I have been a heavy user of the new-workdir script to maintain my build environments, but I always have the HEAD of these workdir's detached, so I can easily switch my arrangement to use the "git worktree" without losing any flexibility. Perhaps we should remove it, possibly leaving a tombstone file like how we removed stuff from the contrib/examples directory.
