Re: [PATCH v3 10/11] contrib: remove "git-new-workdir"

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Sep 12, 2025, 18:14 UTC
Message-ID: <CALnO6CBDcDEXe3a_mpdwTi7ujL-fU5QrDeK704X+5bbkpNgb5w@mail.gmail.com>
In-Reply-To: <e6003a2c-bc1b-4cf5-aae7-ef5aa9c82f10@gmail.com>

On Mon, Sep 8, 2025 at 11:23 AM Gabriel Scherer <gabriel.scherer@gmail.com> wrote:

Show 17 quoted lines

> On 08/09/2025 11:58, Kristoffer Haugsbakk wrote:
> > On Mon, Sep 8, 2025, at 11:28, Gabriel Scherer wrote:
> >> I understand
> >> why its designers felt that this would provide better guarantees (it
> >> is not a good idea to mutate branch names that are checked out
> >> somewhere else), but checking out various branches to test them and
> >> inspect their code (before returning to the feature branch I am
> >> actively working on) is a common part of my workflow.
> >
> > I agree, that’s a great use of worktrees.  But I never feel like I have
> > to checkout the branch itself.  I detach on top of the branch.
>
> I'm afraid `git checkout -d` is not part of my typical git workflow. I
> could retrain myself to use it, when I get into a worktree error, but it
> is cumbersome to know of this new complexity¹, and various things work
> less well in detached state -- for example my bash prompt tells me in
> which branch I am, and in detached state it only shows the commit hash.

From a quick glance, the old script symlinks various repository state together. You could probably get something equally useful out of

    git clone --shared . ../new-worktree

(Provide branch options, etc., as desired?)

With "git config --global alias.new-workdir 'clone --shared'" or similar, you might even have less finger re-training to do.

Alternatively, you could maintain the script yourself by e.g. copying it to somewhere on your $PATH or extracting the contrib/workdir history into a repo of your choice.

-- 
D. Ben Knoble