From: Eric Sunshine <sunshine@sunshineco.com>
To: "Jonathan Müller" <jonathanmueller.dev@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Bug: git worktree remove and overwritten directory
Date: Mon, 8 Jun 2020 02:42:05 -0400 [thread overview]
Message-ID: <CAPig+cTpcgunPNKrzfqKYRb3gVhYff7UiBza-xaTH9GqH_Y+gA@mail.gmail.com> (raw)
In-Reply-To: <dd7c3a11-6537-74ec-053c-0c9c946c5f19@gmail.com>
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.
> > 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/
next prev parent reply other threads:[~2020-06-08 6:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 10:36 Bug: git worktree remove and overwritten directory Jonathan Müller
2020-05-20 13:38 ` Shourya Shukla
2020-05-20 14:22 ` Eric Sunshine
2020-05-20 14:28 ` Jonathan Müller
2020-06-08 6:42 ` Eric Sunshine [this message]
2020-06-08 14:07 ` Jonathan Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPig+cTpcgunPNKrzfqKYRb3gVhYff7UiBza-xaTH9GqH_Y+gA@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=jonathanmueller.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).