git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] Make "git branch -d" prune missing worktrees automatically.

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Nov 9, 2019, 11:34 UTC
Message-ID
<CAPig+cS9KXAH2+gUTV+q9p95Dc20TOt5naN5uH1_TjSaeL53rw@mail.gmail.com>
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:
Show 12 quoted lines
> 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
Previous: Phillip WoodNext: SZEDER Gábor
Message 14 of 15 in “Make die_if_checked_out() ignore missing worktree checkouts.”
  1. 1/2 Make die_if_checked_out() ignore missing worktree checkouts.Peter Jones, Oct 17, 2019
  2. 2/2 Make "git branch -d" prune missing worktrees automatically.Peter Jones, Oct 17, 2019
  3. Eric SunshineOct 17, 2019
  4. Peter JonesOct 18, 2019
  5. 1/4 libgit: Add a read-only helper to test the worktree lockPeter Jones, Oct 18, 2019
  6. 2/4 libgit: Expose more worktree functionality.Peter Jones, Oct 18, 2019
  7. Junio C HamanoOct 21, 2019
  8. 4/4 Make "git branch -d" prune missing worktrees automatically.Peter Jones, Oct 18, 2019
  9. 3/4 Make die_if_checked_out() prune missing checkouts of unlocked worktrees.Peter Jones, Oct 18, 2019
  10. Junio C HamanoOct 21, 2019
  11. Junio C HamanoOct 21, 2019
  12. Eric SunshineNov 8, 2019
  13. Phillip WoodNov 8, 2019
  14. Eric SunshineNov 9, 2019
  15. SZEDER GáborOct 17, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.