Re: "git worktree repair" modifies the wrong repository

[Eric Sunshine <sunshine@sunshineco.com>]

On Thu, Sep 19, 2024 at 6:16 AM Russell Stuart
<russell+git.vger.kernel.org@stuart.id.au> wrote:
> I can't resist pointing out if "git worktree add" had of preserved the
> relative paths I gave it, it would not have happened.

The idea of relative paths has been discussed previously[*] but was
never implemented; although they may help some cases, they break other
cases or at least make the other cases more difficult. For instance,
relative paths only help if the main and linked worktrees move
together in some uniform fashion, but don't help if they move in
distinct ways. Storing *both* the absolute and relative paths rather
than only the absolute path was also discussed and seemed promising,
but concerns were raised that doing so could break other Git-related
tools or non-canonical Git implementations (or even perhaps older
versions of Git itself), thus was never pursued.

FOOTNOTES

[*] The previous discussion was in the context of an earlier
implementation of git-worktree, long before there was a "repair"
subcommand. In fact, the very original implementation of linked
worktrees (which was actually `git checkout --to=<path>` would attempt
to automatically repair itself whenever any Git command discovered
some sort of breakage, however, that initial implementation was buggy
in some fashion (I don't have the details at hand), so the auto-repair
feature was removed very early on. The "repair" subcommand came much
later and took the conservative approach of addressing common problems
people were reporting at the time, and was extended as new reports
came in, rather than trying to tackle every possible way in which
someone could wield a foot-gun.