On 12/09/2025 20:14, D. Ben Knoble wrote:

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

Quick testing seems to indicate that --shared shares less than I would 
expect / am used to. For example, the remotes are not shared (unlike 
with `git worktree` and `new-workdir`).

I currently have 73 remotes configured for the repository I am creating 
workdirs for, and I am happy to keep them configured in a single place.

(The fact that the branch state is synchronized between all 
workdirs/worktrees is also a feature for my use-case, I don't have to 
constantly re-synchronize the work{dirs,trees} for my usage.)

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.

I have a naive question. 'workdir' is a script that has been around for 
a long while, and apparently causes no maintenance burden whatsoever. It 
was removed based on the impression that nobody was using it (let me 
quote the patch description at the end of the present email) -- I 
certainly understand that it is hard to gather information about this. 
My question: now that it is clear that some people are using it, what is 
the reason not to include it again in the contrib/ repository of git 
upstream? If Patrick is not interested in reverting this change, would I 
be welcome in sending a patch to do so?


I feel like I am making git developers relive the "workflow" xkcd comic 
(  https://xkcd.com/1172/ ). But I have the impression that 'git 
worktree' really has an interface limitation in the way 'checkout' is 
restricted; I would be happy to migrate to it if there was a way to 
disable this limitation. My use-case is to have several working 
directories for a single shared instance of a git directory, in such a 
way that I can work in each working directory independently of the 
others. In contrast 'worktree' puts limits/constraints, for a given 
workdir, depending on the state of the *other* workdirs, which would 
force me to have a global map in mind of the state of each workdir.


From: Patrick Steinhardt <redacted>

The "git-new-workdir" command has been introduced to make it possible to
have a separate working directory in a different place. 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.

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.
Remove it as well as the tests that depend on it.