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

From: Gabriel Scherer <gabriel.scherer@gmail.com>
Date: Sep 12, 2025, 18:55 UTC
Message-ID: <b4628cc8-3aad-4911-bcd1-6880d7707250@gmail.com>
In-Reply-To: <CALnO6CBDcDEXe3a_mpdwTi7ujL-fU5QrDeK704X+5bbkpNgb5w@mail.gmail.com>

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

Show 6 quoted lines

>  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 <ps@pks.im>

Show 10 quoted lines

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