Caleb White <cdwhite3@xxxxx> writes: > On Thu Nov 28, 2024 at 9:14 PM CST, Junio C Hamano wrote: >> Caleb White <cdwhite3@xxxxx> 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.
