Re: [RFC PATCH] status: avoid reporting worktrees as "Untracked files"

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

> I doubt you're the only one, but, based upon, list emails over the
> years, it seems that both in-main-tree and outside-main-tree (often
> sibling) worktrees are common. More recently, we've also heard from
> people who don't even have a main-worktree; instead, they hang their
> multiple worktrees off of a bare repository (which is an
> explicitly-supported use-case); i.e.:
>
>     git clone --bare https://.../foobar.git
>     git -C foobar.git worktree add worktree1
>     git -C foobar.git worktree add worktree2
>     ...

I am not sure why you brought in that layout in this discussion,
because it places worktree1 and worktree2 next to each other, just
like placing worktree1 and worktree2 next to the non-bare repository.

    git clone https://.../foobar.git foobar
    git -C foobar worktree add worktree1
    git -C foobar worktree add worktree2

The layout to create worktrees attached to a bare repository and add
them next to each other, and the same starting from a non-bare
repository, share an important trait.  They do not have an untracked
and untrackable "cruft" in their working tree, unlike the crazy
layout that places worktrees of the repository inside the working
tree of the primary worktree as untracked subdirectories.

Really, what is the advantage of doing so?  It is not like the build
recipe recorded in the primary worktree can work recursively on
different branches that are checked out---worktree names and paths
at which they are checked out are totally local matter, and the
upstream project that supplies the build recipe would not know or
care.

Even worse, when the project wants to add a new subdirectory or a
file, the name chosen for the subdirectory may happen to collide
with the name of an untracked subdirectory you happened to have used
(again, because the worktree names and locations are totally local
matter, the upstream project are unaware of them and cannot avoid
such name clashes even if they cared).  You can imagine the
confusion that happens to your next "git pull".

Compared to such an insanity, attaching worktrees to a bare
repository, so that all worktrees are equals and there is no
"primary" worktree that you cannot remove, behave just as normal as
a set of worktrees attached to a non-bare repository and sit outside
the primary worktree, often as immediate siblings.