On Sun, Oct 27, 2024 at 08:17:24PM -0400, Taylor Blau wrote:
> On Fri, Oct 25, 2024 at 10:29:37PM +0000, Caleb White wrote:
> > This patch 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).
> >
> > 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 helper function, `write_worktree_linking_files()`, centralizes
> > the logic for computing and writing either relative or absolute
> > paths, based on the provided configuration. This function accepts
> > `strbuf` pointers to both the worktree’s `.git` link and the
> > repository’s `gitdir`, and then writes the appropriate path to each.
>
> Looking at the patch below, it is quite large, and I wonder if it would
> benefit from being split into smaller pieces. Perhaps factoring out
> write_worktree_linking_files() in a separate patch would be a good start
> here?
Additionally, it appears that this patch breaks at least t0001-init.sh,
but others as well. The relevant portion of -vx from t0001.46 is:
--- 8< ---
+ git -C mainwt config worktree.useRelativePaths true
+ git -C mainwt worktree add --detach ../linkwt
Preparing worktree (detached HEAD 89e2b84)
HEAD is now at 89e2b84 gumby
+ git -C mainwt init --separate-git-dir ../seprepo
Reinitialized existing Git repository in /home/ttaylorr/src/git/t/trash directory.t0001-init/seprepo/
+ git -C mainwt rev-parse --git-common-dir
fatal: repo version is 0, but v1-only extension found:
relativeworktrees
--- >8 ---
Let's please fix this breakage, and then decide what we are going to do
with the extension in the second patch relatively soon, as I worry that
putting the original topic on master may have been a mistake if it is
going to break worktree pruning on earlier Git versions.
Thanks,
Taylor
