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

[Patrick Steinhardt <ps@pks.im>]

On Tue, May 06, 2025 at 12:57:55PM -0700, Junio C Hamano wrote:
> 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