Caleb White <cdwhite3@xxxxx> writes: > You're correct in that the worktree ids are only relevant within the > context of a single repository. However, I've already demonstrated that > it's possible for a repository to "repair" (i.e., take over) a worktree > belonging to another repository if the ids match (inferred backlink). I know. But isn't that a BUG in the code that "repair"s? If a worktree had a name 'develop' that was OK in the context of repository X, and when you "repair" things so that it becomes one of the worktrees of a different repository Y, the "repair" operation is what MUST make sure that the worktree that used to be known as 'develop' to repository X does not interfere any existing worktrees that is attached to the repository Y. If the repository Y already had a worktree called 'develop', the "repair" operation must make sure that the newly adopted worktree would get a different name. But then, the concern is exactly the same when you try to create a new worktree (no "repair" involved) in repository Y and try to give it a name 'develop', isn't it? You have to make sure that there is no worktree that is called 'develop' in the repository Y before giving it the name. Is it broken? If not, what are we doing to make sure we won't give the name 'develop' to the new worktree? Certainly we do not use any hash or random number for that, so why does this new series need to use a random number?
