From: Eric Sunshine <sunshine@sunshineco.com>
To: Phillip Wood <phillip.wood@dunelm.org.uk>
Cc: "Peter Jones" <pjones@redhat.com>,
"Git List" <git@vger.kernel.org>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH 2/2] Make "git branch -d" prune missing worktrees automatically.
Date: Sat, 9 Nov 2019 06:34:53 -0500 [thread overview]
Message-ID: <CAPig+cS9KXAH2+gUTV+q9p95Dc20TOt5naN5uH1_TjSaeL53rw@mail.gmail.com> (raw)
In-Reply-To: <8c583f0c-c359-0fbe-2ffa-304db82b0a86@gmail.com>
On Fri, Nov 8, 2019 at 9:56 AM Phillip Wood <phillip.wood123@gmail.com> 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
next prev parent reply other threads:[~2019-11-09 11:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 16:28 [PATCH 1/2] Make die_if_checked_out() ignore missing worktree checkouts Peter Jones
2019-10-17 16:28 ` [PATCH 2/2] Make "git branch -d" prune missing worktrees automatically Peter Jones
2019-10-17 17:28 ` Eric Sunshine
2019-10-18 19:43 ` Peter Jones
2019-10-18 19:45 ` [PATCH v2 1/4] libgit: Add a read-only helper to test the worktree lock Peter Jones
2019-10-18 19:45 ` [PATCH v2 2/4] libgit: Expose more worktree functionality Peter Jones
2019-10-21 1:59 ` Junio C Hamano
2019-10-18 19:45 ` [PATCH v2 3/4] Make die_if_checked_out() prune missing checkouts of unlocked worktrees Peter Jones
2019-10-21 2:09 ` Junio C Hamano
2019-10-18 19:45 ` [PATCH v2 4/4] Make "git branch -d" prune missing worktrees automatically Peter Jones
2019-10-21 1:36 ` [PATCH v2 1/4] libgit: Add a read-only helper to test the worktree lock Junio C Hamano
2019-11-08 10:14 ` [PATCH 2/2] Make "git branch -d" prune missing worktrees automatically Eric Sunshine
2019-11-08 14:56 ` Phillip Wood
2019-11-09 11:34 ` Eric Sunshine [this message]
2019-10-17 16:44 ` [PATCH 1/2] Make die_if_checked_out() ignore missing worktree checkouts SZEDER Gábor
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+cS9KXAH2+gUTV+q9p95Dc20TOt5naN5uH1_TjSaeL53rw@mail.gmail.com \
--to=sunshine@sunshineco.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=pjones@redhat.com \
--cc=szeder.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).