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

From: Kristoffer Haugsbakk <code@khaugsbakk.name>
Date: Sep 6, 2023, 17:29 UTC
Message-ID: <f782d554-d588-467e-806f-420549ed2f5a@app.fastmail.com>
In-Reply-To: <CAPMMpogm2tr0dy1nsV9NtF4O8-JS=_L3J0+yKRc7KbyAJ-PNbQ@mail.gmail.com>

On Tue, Sep 5, 2023, at 18:25, Tao Klerks wrote:

Show 9 quoted lines

> Fwiw, Eric's reading was my intended one. The people I have spoken
> with, as well as myself, have started using "git worktree" by doing
> the former, and only later felt really transgressive when placing the
> worktrees explicitly on a higher level, on equal footing with the
> "main worktree". To me it seemed natural that the "nested worktrees"
> approach was the expected one, as otherwise it gets even harder to
> explain/justify the operational difference between the "main worktree"
> and the other worktrees - then leading to the bare+worktrees approach
> to eliminate that operational difference.

Let's consider a use-case that `git-worktrees` can replace: just cloning the repository again to do some particular task.

My coworkers have to work on some branch `divergent` which requires a complete rebuild of the project compared to the main branch. But they also need to work on small derivative branches of the main branch. In order to not rebuild all the time they simply cloned the project again and work in *that* repository when working on `divergent`. And since this is an Intellij project it was cloned in the same directory as the original clone.

Replacing this use-case with `git worktrees` would be:

    git worktree ../divergent-project

In this case, `git worktrees` is a more streamlined and better version of cloning a separate repository:

1. Only one object store
2. No need to remember to fetch from both
3. No risk of forgetting that you have some n-iary clone on your machine
   with original work

But crucially they also had the luxury of just cloning the project again since it is less than 1GB; people with larger repositories (like yourself) might have to immediately use the streamlined approaches like `git worktree` since the straightforward approaches are too costly.

So I think the sibling directory tree makes sense when you arrive at this command/workflow from the brute-force approach. But maybe that's not the case when you have to design the proper way of doing it up-front(?)

> Is there a manual for "expected typical usage of git worktree" somewhere?

The example in “Description” of `man git-worktree` uses a sibling directory: `git worktree ../hotfix`.

Show 26 quoted lines

>> Even though deriving the worktree(s) from a separate and protected
>> bare repositories does protect you from total disaster caused by
>> removing "rm -fr" and bypassing "git worktree remove", it still
>> should be discouraged, as the per-worktree states left behind in the
>> repository interfere with the operations in surviving worktrees.
>
> Right, that's fine. Of course you're going to encourage deleting the
> worktrees carefully... but equally of-course, some people *will* do
> "rm -fr that-worktree-I-dont-know-how-to-clean", and when they do,
> telling them "just 'git worktree repair'" is much easier than telling
> them to "recover deleted files 'cause your local branches just
> evaporated"
>
>> Teaching folks not to do "rm -fr" would be the first step to a more
>> pleasant end-user experience, I would think.
>
> The less arcane trivia you *need* to teach users for them to be
> effective, the better the experience is for everyone.
>
> The fact that "deleting a standalone git repo only deletes what's in
> that standalone git repo the way you've done your whole life, but in
> this environment what look like multiple repos are actually
> 'worktrees', if you ever delete one your life *might*, if you choose
> the wrong one, suddenly be very unpleasant" is arcane trivia, in my
> opinion. Better to set things up so they *can't* shoot themselves in
> the foot with a bullet of that caliber.

I don't see how the principle of respecting the level of abstraction doesn't apply here.

Before you might be able to delete a branch `b` by doing `git rm .git/refs/heads/b` and be content when that either finishes successfully or when it complains that the file doesn't exist; you can feel confident that there is no more `b` branch. Now though the ref `b` might be a *packed ref*, so you cannot do that and be sure that the ref was removed.

So if you create a worktree with `git worktree`, you should probably remove it with the same command.

(Am I missing something? I probably am. I might not have understood the context for wanting to run rm(1) on these directories.)

Personally I like to conceptualize worktrees as having equal status to each other as far as me (the user) is concerned, since there isn't anything you can do in the main worktree–or at least I haven't found anything like that—that I *can't* do in a worktree *at that level of abstraction* (directly manipulating files in the `.git` or `repository.git` directory doesn't apply to this level of abstraction, so that the linked worktrees only have a gitfile is irrelevant here).

-- 
Kristoffer Haugsbakk