Re: [PATCH 0/2] Ensure unique worktree ids across repositories

[Junio C Hamano <gitster@pobox.com>]

Caleb White <cdwhite3@pm.me> writes:

> On Thu Nov 28, 2024 at 9:14 PM CST, Junio C Hamano wrote:
>> Caleb White <cdwhite3@pm.me> writes:
>>
>>> The `es/worktree-repair-copied` topic added support for repairing a
>>> worktree from a copy scenario. I noted[1,2] that the topic added the
>>> ability for a repository to "take over" a worktree from another
>>> repository if the worktree_id matched a worktree inside the current
>>> repository which can happen if two repositories use the same worktree name.
>>
>> Problem worth solving.  Another would be to fail if the worktree ID
>> proposed to be used is already in use, but the ID is supposed to be
>> almost invisible (unless the user is doing some adiministrative work
>> on the repository), generating a unique ID is a good approach.
>
> There's already a `while` loop that tries incrementing the proposed id
> (e.g., `develop1` if `develop` is taken). However, this is on
> a per-repository basis, so there's no way to know what's already in use
> in another repository.

Usually repositories on a single host are not aware of each other,
so I am not sure if it is a sensible goal to begin with, to try to
ensure a worktree ID is unique "across repositories".

> The problem arises when trying to run `worktree
> repair` on a worktree that has a matching id (like `develop`) from
> another repository. The goal here is that the same worktree name can be
> created in different repositories and the id will be (effectively)
> unique.

OK, but wouldn't that change the problem we need to solve greatly?

The problem is very much simplified, in fact.  When we are adding to
.git/worktrees/ of a single repository, we need a unique worktree ID
given to the new worktree.  And the ID like `develop` taken from
another repository may or may not be already in use here.

In a repository, a directory ../foo/develop may already be
registered as its worktree, and the user may try to add yet another
directory ../bar/develop as a new worktree.  The first one has been
using 'develop' as its ID, and the "worktree add" command to create
the new one needs to tweak the basename 'develop' to make it unique
within this single repository.  Shouldn't `repair` that tries to
bring in an orphaned worktree that used to be given a worktree ID by
a potentially different repository (or it could be initially created
in this repository and then forgotten, and in the meantime there
could have been many iterations of `develop` worktrees created for
the repository and while it was missing, its ID plus serial number
may have already taken) follow the same pattern?  Whatever worktree
ID that the other repository gave it is invalid in the context of
this repository, anyway.

So I am not sure why we need to complicate the system by adding
random number, which does not help in ensuring uniqueness (it may
make it less likely to collide, but that is different from
guaranteeing uniqueness), while misleading readers that somehow
these numbers after the worktree IDs are serving some purpose.

Am I missing something?

Thanks.