On Tue, Oct 11, 2016 at 1:36 AM, Junio C Hamano <gits...@pobox.com> wrote: > Duy Nguyen <pclo...@gmail.com> writes: > >>> I think there are some pros and some cons for relative path and absolute >>> path. >>> Maybe append a "--relative" option with `git worktree add` ? >>> >>> I've converted all path to relative and all work with success. >>> >>> What do you think to append this --relative option. >> >> Patches are welcome. > > Hmm, are they really welcome? > > Is an invocation of "git worktree add" really the right point in the > workflow to decide if these references to other repositories should > be relative or absolute? When you are moving referrer, it is more > convenient if the reference uses absolute path to name the > referrent. When you are moving both referrer and referrent, it is > more convenient to use relative.
You're right (thanks for thinking this through). There's another case that benefits from relative paths besides Stephane's use case: if you put the entire repo and all associated worktrees on a portable disk, the disk could be mounted on different paths each time, so absolute paths do not fly. > I somehow doubt that users know which future move they would be > making when doing "git worktree add". > > To me, this almost looks like a need for a new subcommand to "git > worktree" that lets you move existing worktree to elsewhere, or turn > absolute reference to relative and vice versa. An alternative is always use relative paths. You have to move worktrees with "git worktree move". Which simplifies things a bit (absolute -> relative conversion on existing worktrees could be done at move time). But I'm not sure if it's a good idea to kill manual move support. If you accidentally move a worktree, it'll be disconnected and you have to fix that by yourself. -- Duy
