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

["Kristoffer Haugsbakk" <code@khaugsbakk.name>]

Hi again Junio

On Wed, Sep 6, 2023, at 22:26, Junio C Hamano 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.

This gives the same error if `there` is a bare repository. Is that
intended?

This goes back to my point about missing nomenclature: it's weird if the
“main working tree” can be a bare repository.

PS: Is it correct that the error message says “main working tree” instead
of “main worktree”? (See cc73385cf6 (worktree remove: new command,
2018-02-12.) I was thinking of spelunking the history further but thought
that I would quickly ask in case I'm missing something obvious.

> It probably does not add much value to introduce a new term
> "inline".

The reason that I like it is because it lets you describe a bare
repository with linked worktrees. Not because it would replace “main
worktree”.

Although in light of Sergey's post about inline/attached, the “main
worktree” term *might* start to look a bit anachronistic. But I'm not
sure.

> 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 applaud whoever wrote this sentence for packing so much good
> information in a concise and easy-to-understand description.

I agree that it is very elegant.

> Perhaps we should borrow it to update the glossary, like so?

Certainly. But although this looks like it completely describes everything
that you want, I still think it is good to explicitly mention something
like:

  “ Note that a bare repository may have ...

Since although this can certainly be inferred from the text, it's good to
have some redundancy when it comes to non-obvious cases.

Cheers

-- 
Kristoffer Haugsbakk