Re: 'git worktree repair' can't repair when main and linked worktrees are moved

[Eric Sunshine <sunshine@sunshineco.com>]

On Fri, Dec 4, 2020 at 6:14 PM Philippe Blain
<levraiphilippeblain@gmail.com> wrote:
> I've had to move all my Git clones to a new filesystem.
> Several of them use secondary worktrees, and all are
> at the same level ex:
>
> I had hoped to use the new 'git worktree repair' command
> but it seems it does not work for this use case.
>
> Is this supposed to work ? Or it's not something that
> 'git worktree repair' can currently cope with ?

This is a situation which `git worktree repair` can not yet handle.
The implementation of bare bones `git worktree repair` was
sufficiently complex that I decided that additional cases like this
and other bells and whistles should be built later atop the basic
implementation. At present, only the following cases are handled:

* secondary worktree has moved so main worktree doesn't know where it
is, but secondary worktree still knows where main worktree is, thus
`git worktree repair` within the secondary can contact the main and
fix up main's reference to the secondary

* main worktree has moved so secondary worktrees don't know where it
is, but main worktree still knows where secondary worktrees are, thus
`git worktree repair` within main can contact each secondary and fix
up their references back to main

There was a little discussion during review[1,2,3] about how the
situation might be handled in which both main and secondary worktrees
have been moved. Primarily, a new command-line option would be added
allowing the user to tell `git worktree repair` where the main
worktree is, in addition to also giving the paths to the secondary
worktrees as arguments (the latter of which is already supported). Now
that I'm thinking about it, I realize also that if invoked in the main
worktree, then `git worktree repair` can recognize that it is
operating in the main worktree (and infer the value of the new
command-line option for specifying location of the main worktree),
thus the user would only have to supply paths to the secondary
worktrees as arguments. My main concern with inferring too much
automatically is that the command could be used to hijack a worktree
belonging to another repository (but perhaps that's a case of "don't
do it if it hurts").

Of course, we could also get more fancy and provide some way to
specify path transformations. For instance, `git worktree repair
--map-path=/old/path:/new/path` might make it possible to repair links
in both directions by applying the path transformation to the paths
involved in the repair. However, this idea is barely germinated; it's
far less well thought out than the previous one.

[1]: https://lore.kernel.org/git/CAPig+cT-w6LV490MGNyG_ihWkSzdgfnEBrjQCsafjndTRmMgFA@mail.gmail.com/
[2]: https://lore.kernel.org/git/xmqqlfi0qaru.fsf@gitster.c.googlers.com/
[3]: https://lore.kernel.org/git/CAPig+cT-ipENZQ39wpaGukRzx3d52OatKEXjWc3_mv56jMbDRg@mail.gmail.com/