From: Jonathan Müller Date: Mon, 08 Jun 2020 14:07:39 GMT Subject: Re: Bug: git worktree remove and overwritten directory Message-ID: In-Reply-To: On 08.06.20 08:42, Eric Sunshine wrote: > On Wed, May 20, 2020 at 10:28 AM Jonathan Müller > wrote: >> On 20.05.20 16:22, Eric Sunshine wrote: >>> Git tries hard to prevent the same directory from being registered to >>> multiple worktrees, however, there is not much it can do to prevent a >>> person from shooting himself in the foot by making changes like this >>> outside of Git's control. Thus, this seems like a case of "if it >>> hurts, don't do it". >> >> I agree and didn't expect git to "work". > > I just posted a patch series[1] which enhances "git worktree prune" to > detect and deal with multiple worktree entries referencing the same > path. Excellent, thank you! > >>> However, "git worktree" could possibly do a better job of helping you >>> recover from such a situation. In particular, I think it should be >>> reasonably easy to enhance "git worktree prune" to detect this >>> situation and automatically prune the non-main now-bogus worktree >>> entry. >> >> At the very least, the somewhat confusing error message could be >> replaced by a "you messed up the worktrees, please delete the >> corresponding entry in .git/worktree" or something like that. But >> enhancing `git worktree prune` would be better. It was, in fact, the >> first command I ran to try and fix the problem. >> >> As said above, I think git worktree remove could issue a better error if >> it detects multiple worktrees with an identical path. > > Hmm, the message it printed complaining that you tried removing the > main worktree seems pretty accurate since that extra worktree entry > was indeed pointing at the main worktree. I suppose it would be > possible to have "git worktree remove" also perform "corruption > detection" so as to present additional information which might clarify > the complaint. Of course, if that is done, then it would make sense to > make all "git worktree" commands likewise report corruption. However, > I haven't convinced myself that we need to go that far. Anyhow, the > posted patch series[1] addresses the immediate problem. > > [1]: https://lore.kernel.org/git/20200608062356.40264-1-sunshine@sunshineco.com/T/ > You're probably right. Fixing git worktree prune to handle the situation is sufficient for me, as that was what I tried. Thanks a lot, Jonathan