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

From: Tao Klerks <tao@klerks.biz>
Date: Sep 5, 2023, 16:10 UTC
Message-ID: <CAPMMpog3o=DtOrC9L6ED42XkegdObkh3rGm617q4u2oofBC1TA@mail.gmail.com>
In-Reply-To: <CAPig+cTeQDMpWQ-zCf6i9H-yhrdCndX6gs67sypuqmHZZcHm7w@mail.gmail.com>

On Tue, Sep 5, 2023 at 2:26 AM Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 17 quoted lines

>
> On Mon, Sep 4, 2023 at 10:41 AM Tao Klerks <tao@klerks.biz> wrote:
> >
> > One problem that we found users to have, early on when we introduced
> > worktrees, was that it was not obvious to users that there was (or why
> > there was) a "main" worktree, containing the actual ".git" repo, and
> > "subsidiary" worktrees, in the same directory location. Git by default
> > makes worktrees *subfolders* of the initial/main worktree/folder, but
>
> This is not accurate. There is no default location for new worktrees;
> git-worktree creates the new worktree at the location specified by the
> user:
>
>     git worktree add [<options>] <path> [<commit>]
>
> where <path> -- the only mandatory argument -- specifies the location.
>

Right - I know you *can* create worktrees in the "parent path", and now that I revisit the doc I see there are even a couple examples that do exactly that - but whenever I've talked with people who've tried "git worktree add" independently, they ended up with the nested worktrees and wondering why things work this weird way.

The idea that the "most trivial" example of creating a worktree would be "git worktree add ../my_new_worktree" is, I believe, very non-obvious.

The other thing that is I believe is non-obvious, in the current solution, is that *if* you end up placing multiple worktrees at the same level, *and* you end up using them "interchangeably" as you presumably would in some or most scenarios, even though their *usage* is identical, their "importance", or "lifetime" is very much not.

>
> It indeed was designed to work this way. It is perfectly legitimate to
> create worktrees attached to a bare repository[1].
>

Awesome, thx for confirming!

> in a bare repository
> scenario, the term "main worktree" refers to the bare repository, not
> to the "blessed" worktree containing the ".git/" directory (since
> there is no such worktree in this case).

Noted, thank you. We have been using the word "repository" vs worktree
- the (main) GITDIR is the repo, the worktrees are all just worktrees.
There is no "main worktree" in the way we talk about things, although
clearly the official nomenclature doesn't square with that, which I
might need to address at some point.

Show 20 quoted lines

> Worktrees appear to be a red-herring. It's possible to reproduce this
> error without them. For instance:
>
>     % git clone --bare --filter=blob:none
> https://github.com/ksylor/ohshitgit dangit_shared.git
>     % git clone dangit_shared.git foop
>     % cd foop
>     % echo nothing >nothing
>     % git add nothing
>     % git commit -m nothing
>     fatal: unable to read dbbb0682a7690b62ccf51b2a8648fa71ac671348
>     % git push origin master
>     % cd ../dangit_shared.git
>     % git gc
>     ...
>     warning: Failed to write bitmap index. Packfile doesn't have full
> closure (object bf86ed1b2602ac3a8d4724bcdf6707b156673aac is missing)
>     fatal: failed to write bitmap index
>     fatal: failed to run repack
>

Hmm, I don't really understand what happened there, but it looks to me like you went *much* further off the beaten path by cloning from a partial clone. Afaik that's hard-not-supported...?

Show 9 quoted lines

>
> The former, meaning that your setup should be supported. Citing
> documentation for `core.bare`:
>
>     If true this repository is assumed to be bare and has no working
>     directory associated with it. If this is the case a number of
>     commands that require a working directory will be disabled, such
>     as git-add(1) or git-merge(1).
>

Thanks again!

Show 7 quoted lines

>
> `--separate-git-dir` predates multiple-worktree support by several
> years and is distinct in purpose from --bare and multiple-worktrees
> (in fact, a couple somewhat recent fixes [2,3] were needed to prevent
> --separate-git-dir from breaking worktree administrative data). My
> understand from scanning history is that --separate-git-dir was
> introduced in aid of submodule support and perhaps other use-cases.

OK, so if it is legitimate as-is... why doesn't it set "core.worktree"? At least that way there'd be a solid two-way reference like with "git worktree" worktrees.

Or is the *point* of the submodule and/or other use-cases that the gitdir can't "know" its worktree??

> git-new-workdir predates git-worktree by quite a few years and, as I
> understand it, remains in-tree because it fills a niche not entirely
> filled by git-worktree.

OK, I'll keep my nose out of this one entirely either way, thx :)