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

From: Patrick Steinhardt <ps@pks.im>
Date: May 7, 2025, 06:27 UTC
Message-ID: <aBr9ZhSmbYtRp6o0@pks.im>
In-Reply-To: <xmqqjz6tikak.fsf@gitster.g>

On Tue, May 06, 2025 at 12:57:55PM -0700, Junio C Hamano wrote:

Show 27 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> > 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.
> 
> Yup.  As the original inventor of the concept, I still have one "new
> workdir" I use daily, without any problems, so I think the layout it
> creates (actually, it created 10 years ago) is more or less still OK
> with the current binary.
> 
> But even I do not create a new one (not that I run "git worktree" to
> create an equivalent all that often).  I do not have an objection
> against the removal.
> 
> >  contrib/workdir/.gitattributes  |   1 -
> >  contrib/workdir/git-new-workdir | 105 ----------------------------------------
> >  t/meson.build                   |   1 -
> >  t/t1021-rerere-in-workdir.sh    |  58 ----------------------
> >  t/t3000-ls-files-others.sh      |  19 --------
> >  5 files changed, 184 deletions(-)
> 
> Oops, do we have tests that depend on contrib/ stuff (other than
> completion and prompt, which should have moved up long ago)?  That
> changes the story a bit.

The tests we have only verify that unrelated feature A works well with workdirs created by git-new-workdir(1). So that alone isn't a good enough reason from my point of view to do a full deprecation cycle.

> Shouldn't we do the usual WITH_BREAKING_CHANGES transition, then?

That is a very good question, and something that we should hash out as part of this cleanup.

As you have mentioned, "contrib/" nowadays is expected to work as a staging area for features that aren't quite ready yet, but that should eventually move into Git proper. But if that future never materializes, either because we notice that the feature just doesn't work well or that the interest goes away, then it should be fine to drop that feature without a full deprecation cycle.

To me this feels a bit like the whole point about "contrib/": it is an stepping stone to get something into Git, but we don't provied any guarantees until it has been promoted into Git core.

I know that this is certainly a revisionist attitude, as "contrib/" hasn't really worked like that in the past. I think though that we have outgrown the old concept of "contrib/" for quite a while already, and that it doesn't really work well in its current form. The ecosystem around Git has grown big enough that we don't want to and cannot host it as part of Git itself anymore, so that original need has gone away.

So I think we should rework our "contrib/" policy so that it serves a better purpose in the modern Git ecosystem. It should be a staging area for new features that are experimental. We don't provide guarantees, but we will ensure that things don't bitrot. If they do start to bitrot and nobody cares, we throw them out. If we eventually see that the feature is getting nowhere, we throw it out. Otherwise, if the feature is eventually deemed to be stable enough, we promote it to Git proper and are happy everafter.

If this is something that the project can agree on I'm happy to rewrite "contrib/README" accordingly. Maybe I should even do it without having any consent yet so that it can serve as a starting point for discussion.

Patrick