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

[Sergey Organov <sorganov@gmail.com>]

Tao Klerks <tao@klerks.biz> writes:

> On Wed, Sep 6, 2023 at 10:26 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Tao Klerks <tao@klerks.biz> writes:
>>
>> > 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.