All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Caleb White <cdwhite3@pm.me>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/2] Ensure unique worktree ids across repositories
Date: Fri, 29 Nov 2024 12:14:27 +0900	[thread overview]
Message-ID: <xmqqr06un33g.fsf@gitster.g> (raw)
In-Reply-To: <20241128-wt_unique_ids-v1-0-30345d010e43@pm.me> (Caleb White's message of "Fri, 29 Nov 2024 02:44:24 +0000")

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.

> This series teaches Git to create worktrees with a unique suffix so
> that the worktree_id is unique across all repositories even if they have
> the same name. For example creating a worktree `develop` would look like:
>
>     foo/
>     ├── .git/worktrees/develop-5445874156/
>     └── develop/
>     bar/
>     ├── .git/worktrees/develop-1549518426/
>     └── develop/
>
> The actual worktree directory name is still `develop`, but the
> worktree_id is unique and prevents the "take over" scenario. The suffix
> is given by the `git_rand()` function, but I'm open to suggestions if
> there's a better random or hashing function to use.

I do not think it matters much what hash/rand algorithm is chosen.
What is important is what you do when the suffix suggested by that
chosen algorithm collides with an existing worktree ID.  IOW, there
is no way a "random" can guarantee uniqueness.  Attempt to create and
if you find a collision, retry from the generation of another suffix,
or something like that, is necessary.

And as long as that "make sure it is unique" part is done right, it
does not even have to be random.  Just generating a sequence number
and using the first one that is available would work as well.

Thanks.

  parent reply	other threads:[~2024-11-29  3:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-29  2:44 [PATCH 0/2] Ensure unique worktree ids across repositories Caleb White
2024-11-29  2:44 ` [PATCH 1/2] worktree: add worktree with unique suffix Caleb White
2024-11-29  2:44 ` [PATCH 2/2] worktree: rename worktree id during worktree move Caleb White
2024-11-29  2:49 ` [PATCH 0/2] Ensure unique worktree ids across repositories Caleb White
2024-11-29  3:14 ` Junio C Hamano [this message]
2024-11-29  3:31   ` Caleb White
2024-12-01  4:38     ` Junio C Hamano
2024-11-29 11:05 ` shejialuo
2024-11-29 15:58   ` Caleb White
2024-11-29 17:32     ` shejialuo
2024-11-29 20:39       ` Caleb White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr06un33g.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=cdwhite3@pm.me \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.