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

Tao Klerks [off-list ref] writes:

On Wed, Sep 6, 2023 at 10:26 PM Junio C Hamano [off-list ref] wrote:

quoted

Tao Klerks [off-list ref] writes:

quoted

I like the nomenclature, I like the simple "zero (i.e. bare) or one
inline worktree, zero or more attached worktrees" explanation.

We have used "main worktree" to refer to the working tree part (plus
the repository) of a non-bare repository.  And it makes sense to
explain it together with the concept of "worktree", as the primary
one is very much special in that it cannot be removed.  You can see
that "git worktree remove" would stop you from removing it with an
error message:

        fatal: '../there' is a main working tree.

It probably does not add much value to introduce a new term
"inline".  Here is what "git worktree --help" has to say about it.

    A repository has one main worktree (if it's not a bare repository) and
    zero or more linked worktrees.

I've definitely changed my mind about "inline", I agree "main" is
better. I'm not convinced it's the best word we could come up with,
but if it's well-established, I'm happy with it.

The problem I (now) see with "inline" is that it seems to imply a
spatial proximity that doesn't necessarily hold true, with
"--separate-git-dir" or other ways to separate the main worktree from
its usual "just above the .git directory" location. "Inline" is still
a reasonable qualification of the main worktree's *metadata* in that
situation (index, etc), but I think the word would not be sufficiently
clear/representative overall.

It's not to argue in favor of "inline", just to clarify: I took it from
inline-vs-attached as used in e-mail, where "inline" means that you see
attachment right here, inline with the rest of text.

I also admit I didn't happen to consider --separate-git-dir at the
time.