On Thu, Sep 19, 2024 at 6:16 AM Russell Stuart <russell+git.vger.kernel.org@xxxxxxxxxxxx> 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.
