Hi folks, I've recently encountered some users who've got themselves into trouble by copying a worktree into another folder, to create a second worktree, instead of using "git worktree add". They assumed this would be fine, just the same as creating a new *repository* by copying an new *repository* is generally fine (except when you introduce worktrees, of course). There users eventually understood that something was wrong, as you might expect, when a checkout in one worktree also "checked out" (and produced lots of unexpected changes) in the other worktree - or similar weirdnesses, eg on commit. Ideally, as I user, I would expect git to start shouting at me to "git worktree repair" the moment the mutual reference between the ".git" file of the worktree, and the "gitdir" file of the repo's worktree metadata, stopped agreeing. Is there any reason we can't/don't have such a safety check? (would it be expensive??) I think I can implement something reasonably effective with a pair of hooks (pre-commit and post-checkout look like good candidates), but I'm weirded out that something like this should need to be "custom". I did a quick search of the archives but didn't find anything relevant. Has this been discussed? Should I try to prepare a patch including that sort of validation... somewhere? Thanks, Tao
