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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).