Re: Bug: git worktree remove and overwritten directory

["Jonathan Müller" <jonathanmueller.dev@gmail.com>]

On 08.06.20 08:42, Eric Sunshine wrote:
> On Wed, May 20, 2020 at 10:28 AM Jonathan Müller
> <jonathanmueller.dev@gmail.com> 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