On 08/09/2025 11:58, Kristoffer Haugsbakk wrote:

On Mon, Sep 8, 2025, at 11:28, Gabriel Scherer wrote:

quoted

Dear git developers,

I find myself affected by the removal of the `git-new-workdir` script
which is a relatively common part of my workflow. I am writing to ask
if it might be possible to reinstate the script in `contrib`, and also
possibly create a discussion with other users affected.

(The removal of the script was released in git 2.51, three weeks ago.)

Did you run into this issue when upgrading from 2.50 to 2.51 or from an
older version?  Was it simple to troubleshoot that the script was gone?

I create a new workdir by manually running
/usr/share/doc/git/contrib/workdir/git-new-workdir, so indeed I
quickly found out that the wordir/ folder was gone and this was
clearly a git-side packaging change.

Just curious.  I’m as naïve about release management as any
random person!

quoted

Thanks for your work on git!


## Details/comments

  > The command thus predates git-worktree(1), which is what people use
  > nowadays to create any such working directory. As such, the script
  > doesn't really have much of a reason to exist nowadays anymore.

`git worktree` suffers from the substantial restriction that it is not
allowed for two worktrees to checkout the same branch.

You can override that restriction with `--force`.[1]

† 1: Naming override options just `--force` has some UX issues like
     discoverability and the fact that (in this case) it is used for
     multiple orthogonal things

Thanks. I just tried this, but I think it does not suffice. The --force
option is available to "git worktree add" to create a worktree for a
branch that is already checked out. But typically my workflow is to
create a worktree for a new feature branch, and there from that worktree
temporarily switch to an existing branch using `git checkout`, and there
I get a hard error (if another worktree has this branch) and there is no
--force option to override the worktree limitation at 'checkout' time. I
just tried to test whether worktrees created with --force would allow to
switch to checked-out-in-other-worktrees branches in the future, but
that does not appear to be the case.

quoted

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.

¹: it would be nice if the fatal-error message on 'git checkout' when
trying to checkout a branch that is active on another worktree would
suggest using `git checkout -d` instead to proceed. I may try to send a
patch to add this information.

quoted

Getting a 'fatal
error' because some other, independent worktree also checked this
branch out is a hindrance.

Note: I don't know about the `worktree` implementation and whether the
[snip]