On Fri, Nov 8, 2019 at 9:56 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > On 08/11/2019 10:14, Eric Sunshine wrote: > > Perhaps there is some way to address the pain point without breaking > > the fundamental promise made by git-worktree about being careful with > > worktree metadata[*], but the changes proposed by this patch series > > seem insufficient (even if the patch is reworked to respect worktree > > locking). I've cc:'d Duy in case he wants to chime in. > > I agree that we want to preserve the safe guards in the worktree design. > I wonder if detaching the HEAD of the missing worktree would solve the > problem without losing data. In the case where something wants to > checkout the same branch as the missing worktree then I think that is a > good solution. I think it should be OK for branch deletion as well. I would feel very uncomfortable making "automatic HEAD detachment" (decapitation?) the default behavior. Although doing so may (in some fashion) safeguard precious information in .git/worktrees/<id>, it potentially brings its own difficulties. For instance, if someone takes an action which automatically detaches HEAD of a missing worktree which had some branch checked out (and possibly some changes staged in the worktree-specific "index"), and then builds more commits on that branch, then that worktree gets into a state akin to rebased upstream (for which git-rebase documentation devotes an entire section[1], "Recovering From Upstream Rebase"). While a power-user may be able to recover from such a state, allowing the general Git user to get into such a situation by default seems contraindicated. I'm not even convinced that hiding the suggested "auto-detach" behavior behind a configuration variable so power-users can enable it is entirely a good idea either since, while it may eliminate some pain, it also potentially allows abandoned worktree entries to accumulate. [1]: https://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase
