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

Johannes Schindelin [off-list ref] writes:

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".