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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Sep 5, 2023, 05:43 UTC
Message-ID: <CAPig+cRJhrGmnBRm2dporcXiRr4SzRmpM2LTMm0S7wo0XbOU9Q@mail.gmail.com>
In-Reply-To: <xmqqedjdtoh5.fsf@gitster.g>

On Mon, Sep 4, 2023 at 9:09 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> Eric Sunshine <sunshine@sunshineco.com> writes:
> > 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.
>
> All correct.  The per-worktree part of the repository data does live
> in a subdirectory of the ".git" directory and that was probably what
> Tao had in mind, though.

That could be. I read Tao's explanation as meaning that people do this:

    git clone foo.git foo
    cd foo
    git worktree add bar
    git worktree add baz

rather than (perhaps) this:

    git clone foo.git foo
    cd foo
    git worktree add ../bar
    git worktree add ../baz

But it's possible I misunderstood.

Show 13 quoted lines

> >> Is it the case that this contrib script predates the current "git
> >> worktree" support?
> >
> > 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.
>
> I actually think there is no longer a valid workflow whose support
> by "worktree" is still insufficient and the script has outlived its
> usefulness.  I have been a heavy user of the new-workdir script to
> maintain my build environments, but I always have the HEAD of these
> workdir's detached, so I can easily switch my arrangement to use the
> "git worktree" without losing any flexibility.

My response was based upon my recollection of the periodic message which shows up on the mailing list reporting a bug or submitting an improvement for git-new-workdir, accompanied by a statement that git-new-workdir is still a better fit for the user's particular use-case. But I've never used it myself, so it's good to hear from someone (you) who does use it.

> Perhaps we should remove it, possibly leaving a tombstone file like
> how we removed stuff from the contrib/examples directory.

Perhaps.