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

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Sep 7, 2023, 15:07 UTC
Message-ID: <d59a97e7-81fd-472b-9a18-32d993f8c1c8@app.fastmail.com>
In-Reply-To: <xmqqledjm4k2.fsf@gitster.g>

Hi again Junio

On Wed, Sep 6, 2023, at 22:26, Junio C Hamano wrote:

Show 13 quoted lines

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

Show 7 quoted lines

> 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