Re: Is "bare"ness in the context of multiple worktrees weird? Bitmap error in git gc.

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2023, 01:09 UTC
Message-ID: <xmqqedjdtoh5.fsf@gitster.g>
In-Reply-To: <CAPig+cTeQDMpWQ-zCf6i9H-yhrdCndX6gs67sypuqmHZZcHm7w@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 7 quoted lines

> This is not accurate. There is no default location for new worktrees;
> git-worktree creates the new worktree at the location specified by the
> user:
>
>     git worktree add [<options>] <path> [<commit>]
>
> where <path> -- the only mandatory argument -- specifies the location.

All correct. The per-worktree part of the repository data does live in a subdirectory of the ".git" directory and that was probably what Tao had in mind, though.

Show 10 quoted lines

> It indeed was designed to work this way. It is perfectly legitimate to
> create worktrees attached to a bare repository[1].
>
> [1]: Support for bare repositories in conjunction with multiple-
> worktrees, however, came after the initial implementation of multiple-
> worktrees. An unfortunate side-effect is that established terminology
> became somewhat confusing. In particular, in a bare repository
> scenario, the term "main worktree" refers to the bare repository, not
> to the "blessed" worktree containing the ".git/" directory (since
> there is no such worktree in this case).

Again all correct.

Show 6 quoted lines

>> Is it the case that this contrib script predates the current "git
>> worktree" support?
>
> git-new-workdir predates git-worktree by quite a few years and, as I
> understand it, remains in-tree because it fills a niche not entirely
> filled by git-worktree.

I actually think there is no longer a valid workflow whose support by "worktree" is still insufficient and the script has outlived its usefulness. I have been a heavy user of the new-workdir script to maintain my build environments, but I always have the HEAD of these workdir's detached, so I can easily switch my arrangement to use the "git worktree" without losing any flexibility.

Perhaps we should remove it, possibly leaving a tombstone file like how we removed stuff from the contrib/examples directory.