From: Gabriel Scherer Date: Mon, 08 Sep 2025 15:22:42 GMT Subject: Re: [PATCH v3 10/11] contrib: remove "git-new-workdir" Message-ID: In-Reply-To: <2b3c951b-0400-4cc5-b790-17ff77154ec2@app.fastmail.com> On 08/09/2025 11:58, Kristoffer Haugsbakk wrote: > On Mon, Sep 8, 2025, at 11:28, Gabriel Scherer wrote: >> 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! > >> >> 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. >> 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. >> 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]