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

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.)

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. 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. 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
no-double-checkout restriction is fundamental to its correctness or
just a user-interface feature to avoid sharp edges. I would be happy
to migrate to `worktree` if it was possible to disable it (presumably
via a repository-global parameter, or maybe something
finer-grained). It sounds like more work than just keeping
`git-new-workdir` alive -- but I am sure there are niceties with
`worktree` that migrating users would benefit from.

 > It also doesn't seem like the script is still in use: the last time
 > it has received an update was in e32afab7b03 (git-new-workdir: don't
 > fail if the target directory is empty, 2014-11-26), more than a
 > decade ago.

I use `git-new-workdir` actively, and have never suffered from an issue worth fixing or reporting upstream. The fact that it was last changed a decade ago also suggests that the maintenance cost for git upstream is minimal.