Re: What is the reason behind not hiding git worktrees from git?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 17, 2025, 22:57 UTC
Message-ID: <xmqqikf8gtcq.fsf@gitster.g>
In-Reply-To: <8cc4ca72-c87a-acc1-e200-53be14d649f8@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> that main worktree after verifying with `git status` that there was no
> unfinished business to take care of before deleting the repository.
> Because that secondary worktree (which did contain unfinished business,
> including a carefully crafted series of commits) was now obviously no
> longer a worktree but only a tree without a working `.git`.

Ouch, that is a tough one. It is very hard to interfere and stop your "rm -fr" based on what Git could find (in other words, your "rm" lacks the "pre-something" hook).

Of course, an argument can be made that you should have also asked `git worktree list` if there are other worktrees, in addition to asking `git status`, but I wonder if it would have helped to have the information in the `git status` output so that we can always trust that it is sufficient to ask a single command without doing anything else? As "separate worktrees" is a feature to allow users to more or less independently work in each separate worktree, without having to worry about what they are doing in the other worktrees, cramming too much into `git status` would degrade the end-user experience and it takes a fine balance.

I think that one of the reasons why the "outside the working tree" layout is recommended is to prevent us from "git add ." (or other overly wide pathspec) to accidentally add these embedded worktrees to the main project, but such a mistake is at least not as destructive as "rm -fr".