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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 12, 2023, 23:52 UTC
Message-ID: <xmqqjzqmmsvx.fsf@gitster.g>
In-Reply-To: <CAPig+cQbwcJOQiYyb7bma3pH1hxjE_X_yeAp3JeHWVCeJtySfQ@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 11 quoted lines

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