Re: Bug: git worktree remove and overwritten directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux