Subject: Re: [PATCH v2 0/3] Ensure unique worktree ids across repositories

From: Junio C Hamano <[email-masked]>
Date: Tue, 03 Dec 2024 13:37:59 +0900

Caleb White <[email-masked]> 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?