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

[Gabriel Scherer <gabriel.scherer@gmail.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]