On Fri, Dec 4, 2020 at 6:14 PM Philippe Blain <levraiphilippeblain@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ [2]: https://lore.kernel.org/git/xmqqlfi0qaru.fsf@xxxxxxxxxxxxxxxxxxxxxx/ [3]: https://lore.kernel.org/git/CAPig+cT-ipENZQ39wpaGukRzx3d52OatKEXjWc3_mv56jMbDRg@xxxxxxxxxxxxxx/
