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

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

Hi again Tao

On Thu, Sep 7, 2023, at 06:53, Tao Klerks wrote:
> 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.

Note that the conversation was forked:

1. New nomenclature to describe things more precisely
2. How good those words in themselves are at describing these things

I liked “inline” since it helped to clarify the case of a bare repository
with linked worktrees. Sure, emphasizing that it has no “inline worktree”
might be redundant (it can be inferred, perhaps), it's nice to be able to
emphasize things for pedagogical purposes.

(I'm less sure if “attached” is needed.)

This is what we can say for certain about a repository:

• There definitely is a repository somewhere (maybe not in whatever
  worktree you are in right now though)
• It has zero or more worktrees

So “main worktree” is optional. And that optionality makes things awkward
since it also used to describe where the repository lives—even when the
repository has no *inline worktree* (it is bare).

The bottom line is that it's nice if one can avoid having to get into
situations like this made-up conversation:

A: — I'm in the deployment worktree now. Where's the main
  worktree in our workflow? [I don't know how to use `git worktree`]
B: — That's `repository.git`.
A: — Okay nice. Is that worktree used for the mainline development?
B: — No, it has no worktree. It's bare.
A: — What? But didn't you say that it was the main worktree?
B: — Yes, in the sense that it's where the repository is. But it has no
    worktree itself.

>> We can read that (1) a non-bare repository itself is considered
>> its "main worktree", (2) a bare repository, by inference, has no
>> main worktree (otherwise we wouldn't have said "if it's not"), and
>> (3) both bare and non-bare repositories can have linked worktrees
>> (again, otherwise we wouldn't have brought up a bare repository in
>> the description).
>>
>> Perhaps we should borrow it to update the glossary, like so?
>>
>
> Looks good to me, but that leaves me with a different nitpick: we say
> 'One "worktree" consists of a "working tree" and repository metadata,
> most of which are shared among other worktrees of a single repository,
> and some of which are maintained separately per worktree'
>
> This claims that the *shared metadata* (presumably the refs, the
> branch reflogs, the objects, the config, etc) are *part of the
> worktree* (a worktree "consists of" them and other things). That seems
> like a very strange way to conceive of things, to me.
>
> I would find it reasonable to state that the main worktree is part of
> the repo - certainly that's now most everyday users would think of it,
> if they were made to think of the worktree concept at all - but not
> that the shared repo metadata is part of the worktree, and especially
> not that the shared repo metadata is part of the attached worktrees.

Without getting into the subtle distinctions between is-a and has-a: I
think it could make sense to think of this in terms of which one needs the
other one. A worktree needs a repository, so one could say that a worktree
“consists of” that. A repository on the other hand doesn't need to have
any worktrees.

(But the vice-versa also makes sense.)

> I imagine that this weird phrasing intends to allude to the fact that
> a worktree is "broken" without the repository metadata folder that
> contains both its worktree-specific metadata and the shared metadata
> that it depends just as much on... but can we come up with better
> "relationship words here?

I don't see why one needs to phrase or define things in terms of what
would make it corrupted or not-that-thing any more. Like, a “working tree”
without a Git repository is just a directory tree—it's got nothing to do
with Git whatsoever.

> Sorry to continue nitpicking - I would love to see a clear
> nomenclature and description of these parts and their relationships
> for people (with less git experience) to "get it" more easily.

As a Git user I think this is a very productive topic.

Cheers

-- 
Kristoffer Haugsbakk