From: <rsbecker@nexbridge.com>
To: "'Caleb White'" <cdwhite3@pm.me>, <git@vger.kernel.org>
Cc: "'shejialuo'" <shejialuo@gmail.com>,
"'Junio C Hamano'" <gitster@pobox.com>
Subject: RE: [PATCH v2 0/3] Ensure unique worktree ids across repositories
Date: Fri, 29 Nov 2024 17:54:03 -0500 [thread overview]
Message-ID: <00c401db42b1$99c4d5a0$cd4e80e0$@nexbridge.com> (raw)
In-Reply-To: <20241129-wt_unique_ids-v2-0-ff444e9e625a@pm.me>
On November 29, 2024 5:38 PM, Caleb White 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.
>
>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
>which should be sufficient to ensure that the suffix is effectively unique (the
>likelihood of a collision with the same name and suffix is extremely low).
>
>During a `worktree move` the worktree directory is moved/renamed but the
>repository under `worktrees/<id>` is not updated. For example, moving `develop` to
>`master` results in
>
> foo/
> ├── .git/worktrees/develop-5445874156/
> └── master/
>
>This works because the linking files still point to the correct repository, but this is a
>little weird. This series teaches Git to also move/rename the repository / worktree id
>during a `move` so that the structure now looks like:
>
> foo/
> ├── .git/worktrees/master-1565465986/
> └── master/
>
>Note that a new unique suffix is assigned to reduce the complexity of trying to parse
>and reuse the existing suffix.
>
>Additionally, this series teaches `worktree list` to output the worktree id in the
>verbose and porcelain modes, which allows users and scripts to more easily obtain
>the id for a given worktree.
>
>[1]: https://lore.kernel.org/git/20241008153035.71178-1-cdwhite3@pm.me/
>[2]:
>https://lore.kernel.org/git/r4zmcET41Skr_FMop47AKd7cms9E8bKPSvHuAUpnYav
>zKEY6JybJta0_7GfuYB0q-gD-
>XNcvh5VDTfiT3qthGKjqhS1sbT4M2lUABynOz2Q=@pm.me/
>
>Signed-off-by: Caleb White <cdwhite3@pm.me>
>---
>The base for this series is obtained by merging the `cw/worktree-extension` topic
>(2024-11-26, 20241125-wt_relative_options-v5-0-356d122ff3db@pm.me)
>onto 090d24e9af.
>
>Changes in v2:
>- Add the worktree id to `worktree list` output
>- Updated cover letter
>- Link to v1: https://lore.kernel.org/r/20241128-wt_unique_ids-v1-0-
>30345d010e43@pm.me
>
>---
>Caleb White (3):
> worktree: add worktree with unique suffix
> worktree: rename worktree id during worktree move
> worktree: add id to `worktree list` output
>
> Documentation/git-worktree.txt | 17 +++++--
> builtin/worktree.c | 35 ++++++++++++++
> t/t0035-safe-bare-repository.sh | 4 +-
> t/t0600-reffiles-backend.sh | 10 ++--
> t/t0601-reffiles-pack-refs.sh | 4 +-
> t/t0610-reftable-basics.sh | 54 +++++++++++-----------
> t/t1407-worktree-ref-store.sh | 4 +-
> t/t1410-reflog.sh | 10 ++--
> t/t1415-worktree-refs.sh | 26 +++++------
> t/t1450-fsck.sh | 14 +++---
> t/t1500-rev-parse.sh | 6 +--
> t/t2400-worktree-add.sh | 51 +++++++++++----------
> t/t2401-worktree-prune.sh | 20 ++++----
> t/t2402-worktree-list.sh | 16 ++++---
> t/t2403-worktree-move.sh | 38 ++++++++--------
> t/t2405-worktree-submodule.sh | 10 ++--
> t/t2406-worktree-repair.sh | 93 ++++++++++++++++++++++++--------------
> t/t2407-worktree-heads.sh | 27 +++++------
> t/t3200-branch.sh | 10 ++--
> t/t5304-prune.sh | 2 +-
> t/t7412-submodule-absorbgitdirs.sh | 4 +-
> 21 files changed, 265 insertions(+), 190 deletions(-)
>---
>base-commit: 090d24e9af6e9f59c3f7bee97c42bb1ae3c7f559
>change-id: 20241127-wt_unique_ids-1ffd7ea0bb19
>prerequisite-change-id: 20241025-wt_relative_options-afa41987bc32:v6
>prerequisite-patch-id: 179410e257e8eedf100f4f9faa9467cbbba4d61b
>prerequisite-patch-id: 56ffe0afeadd511c9eef5f548a371659b040acab
>prerequisite-patch-id: 809c1314e5dfa966f4f3d73b52f286f8aa89370f
>prerequisite-patch-id: cf5f9491c8f8e58d1e0e103a5f8c64c55f2896e3
>prerequisite-patch-id: 9884b33822bf4c7c3b89a9a6b49d4ab44c2670e7
>prerequisite-patch-id: 62a09496d98d78a6bd1f9150ba887ee72359c7ee
>prerequisite-patch-id: 5527e4b745963dd4fa08029491fcbfe3d91d5104
>prerequisite-patch-id: bf433443e90939a493fa586de30938f78cb77020
General comment on this series: Is there a mechanism of preserving existing
functionality for those of us who have existing scripts that depend on the
existing branch and worktree naming?
next prev parent reply other threads:[~2024-11-29 22:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 22:37 [PATCH v2 0/3] Ensure unique worktree ids across repositories Caleb White
2024-11-29 22:37 ` [PATCH v2 1/3] worktree: add worktree with unique suffix Caleb White
2024-11-29 22:37 ` [PATCH v2 2/3] worktree: rename worktree id during worktree move Caleb White
2024-11-29 22:37 ` [PATCH v2 3/3] worktree: add id to `worktree list` output Caleb White
2024-11-29 22:54 ` rsbecker [this message]
2024-11-29 23:13 ` [PATCH v2 0/3] Ensure unique worktree ids across repositories Caleb White
2024-11-29 23:17 ` rsbecker
2024-11-29 23:29 ` Caleb White
2024-11-29 23:44 ` rsbecker
2024-11-30 0:08 ` Caleb White
2024-11-30 0:38 ` rsbecker
2024-11-30 16:08 ` Caleb White
2024-11-30 17:16 ` rsbecker
2024-12-02 2:00 ` Junio C Hamano
2024-12-02 11:46 ` shejialuo
2024-12-03 0:46 ` Junio C Hamano
2024-12-03 0:56 ` Eric Sunshine
2024-12-03 1:46 ` Junio C Hamano
2024-12-03 1:53 ` rsbecker
2024-12-03 2:30 ` Junio C Hamano
2024-12-03 3:42 ` Caleb White
2024-12-03 4:37 ` Junio C Hamano
2024-12-03 5:31 ` Caleb White
2024-12-03 1:24 ` shejialuo
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='00c401db42b1$99c4d5a0$cd4e80e0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=cdwhite3@pm.me \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=shejialuo@gmail.com \
/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.