Message ID | 20241031-wt_relative_options-v4-0-07a3dc0f02a3@pm.me (mailing list archive) |
---|---|
Headers | show |
Series | Allow relative worktree linking to be configured by the user | expand |
Caleb White <cdwhite3@pm.me> writes: > The base for this patch series is obtained by applying the following > patch onto 6a11438f43: > - cw/config-extensions topic (doc: consolidate extensions in git-config > documentation, 2024-10-22, <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me>) I am slowing getting back to speed, but with the above I noticed two things. - Do not encourage people to _apply_ random patches before your series when the official tree has the same patches. In this case, you even know the branch the official tree uses (i.e. cw/config-extensions), so tell readers to _merge_ the topic before applying your series instead. - The notes/amlog I snarfed from the broken-out repository of Taylor does not seem to record the message ID <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me> Perhaps I was looking at a wrong repository? Thanks.
On Fri Nov 1, 2024 at 2:14 AM CDT, Junio C Hamano wrote: > Caleb White <cdwhite3@pm.me> writes: > >> The base for this patch series is obtained by applying the following >> patch onto 6a11438f43: >> - cw/config-extensions topic (doc: consolidate extensions in git-config >> documentation, 2024-10-22, <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me>) > > I am slowing getting back to speed, but with the above I noticed two > things. Welcome back! I hope you had a good break :). > - Do not encourage people to _apply_ random patches before your > series when the official tree has the same patches. In this > case, you even know the branch the official tree uses > (i.e. cw/config-extensions), so tell readers to _merge_ the > topic before applying your series instead. Ah, my apologies. I will make sure to do that in the future. When I first added this note, a topic branch[1] had not been created yet and I forgot to update it when it was. > - The notes/amlog I snarfed from the broken-out repository of > Taylor does not seem to record the message ID > <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me> Perhaps > I was looking at a wrong repository? Hmm, I'm not sure. Here's the latest update in the What's Cooking report: * cw/config-extensions (2024-10-22) 1 commit (merged to 'next' on 2024-10-30 at 875fa0b619) + doc: consolidate extensions in git-config documentation (this branch is used by cw/worktree-extension.) Centralize documentation for repository extensions into a single place. Will merge to 'master'? source: <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me> Best, [1]: https://github.com/ttaylorr/git/tree/cw/config-extensions
Caleb White <cdwhite3@pm.me> writes: > Ah, my apologies. I will make sure to do that in the future. When > I first added this note, a topic branch[1] had not been created yet and > I forgot to update it when it was. I see. I think Taylor has done a great job maintaining these topics, so I'll see how well they have been reviewed during the past few weeks. Thanks.
On Fri, Nov 1, 2024, at 08:14, Junio C Hamano wrote: > - The notes/amlog I snarfed from the broken-out repository of > Taylor does not seem to record the message ID > <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me> Perhaps > I was looking at a wrong repository? > > Thanks. You can find that amlog on https://github.com/git/git/
This series introduces the `--[no-]relative-paths` CLI option for `git worktree {add, move, repair}` commands, as well as the `worktree.useRelativePaths` configuration setting. When enabled, these options allow worktrees to be linked using relative paths, enhancing portability across environments where absolute paths may differ (e.g., containerized setups, shared network drives). Git still creates absolute paths by default, but these options allow users to opt-in to relative paths if desired. Using the `--relative-paths` option with `worktree {move, repair}` will convert absolute paths to relative ones, while `--no-relative-paths` does the reverse. For cases where users want consistency in path handling, the config option `worktree.useRelativePaths` provides a persistent setting. A new extension, `relativeWorktrees`, is added to indicate that at least one worktree in the repository has been linked with relative paths. This extension is automatically set when a worktree is created or repaired using the `--relative-paths` option, or when the `worktree.useRelativePaths` config is set to `true`. The `relativeWorktrees` extension ensures older Git versions do not attempt to automatically prune worktrees with relative paths, as they would not not recognize the paths as being valid. Signed-off-by: Caleb White <cdwhite3@pm.me> --- The base for this patch series is obtained by applying the following patch onto 6a11438f43: - cw/config-extensions topic (doc: consolidate extensions in git-config documentation, 2024-10-22, <20241021-cleanup-extension-docs-v1-1-ab02cece3132@pm.me>) Link to original patch series: https://lore.kernel.org/git/20241007-wt_relative_paths-v3-0-622cf18c45eb@pm.me --- Changes in v4: - Fixed failing test in ci - Link to v3: https://lore.kernel.org/r/20241031-wt_relative_options-v3-0-3e44ccdf64e6@pm.me Changes in v3: - Split patches into smaller edits. - Moved tests into the patches with the relevant code changes. - Removed global `use_relative_paths` and instead pass parameter to functions. - Changed `infer_backlink` return type from `int` to `ssize_t`. - Updated `worktree.useRelativePaths` and `--relative-paths` descriptions. - Reordered patches - Link to v2: https://lore.kernel.org/r/20241028-wt_relative_options-v2-0-33a5021bd7bb@pm.me Changes in v2: - Fixed a bug where repositories with valid extensions would be downgraded to v0 during reinitialization, causing future operations to fail. - Split patch [1/2] into three separate patches. - Updated cover letter and commit messages. - Updated documentation wording. - Link to v1: https://lore.kernel.org/r/20241025-wt_relative_options-v1-0-c3005df76bf9@pm.me --- Caleb White (8): setup: correctly reinitialize repository version worktree: add `relativeWorktrees` extension worktree: refactor infer_backlink return worktree: add `write_worktree_linking_files()` function worktree: add relative cli/config options to `add` command worktree: add relative cli/config options to `move` command worktree: add relative cli/config options to `repair` command worktree: refactor `repair_worktree_after_gitdir_move()` Documentation/config/extensions.txt | 6 ++ Documentation/config/worktree.txt | 10 +++ Documentation/git-worktree.txt | 7 ++ builtin/worktree.c | 29 ++++--- repository.c | 1 + repository.h | 1 + setup.c | 39 +++++++-- setup.h | 1 + t/t0001-init.sh | 22 ++++- t/t2400-worktree-add.sh | 54 ++++++++++++ t/t2401-worktree-prune.sh | 3 +- t/t2402-worktree-list.sh | 22 +++++ t/t2403-worktree-move.sh | 22 +++++ t/t2406-worktree-repair.sh | 26 ++++++ t/t2408-worktree-relative.sh | 39 --------- t/t5504-fetch-receive-strict.sh | 6 +- worktree.c | 163 ++++++++++++++++++++---------------- worktree.h | 22 ++++- 18 files changed, 331 insertions(+), 142 deletions(-) --- base-commit: 6a11438f43469f3815f2f0fc997bd45792ff04c0 change-id: 20241025-wt_relative_options-afa41987bc32 prerequisite-change-id: 20241020-cleanup-extension-docs-f365868711bf:v1 prerequisite-patch-id: 60a443b24e92938b9b6f4a016a7bab87e13bf3ea Best regards,