Show 34 quoted lines
>
> On Mon, Apr 27, 2020 at 02:17:32PM -0700, Junio C Hamano wrote:
>
> > If we were to adopt it as an experiment, hoping to gain exposure,
> > nothing above 'master' (or tagged releases) won't work. And once a
> > thing is in 'master', users will ignore the "this is merely an
> > experiment" warning and expect it to be fully functional and usable.
>
> Yeah, that is a problem. I wonder if the state would be more obvious if
> it lived in contrib/. We already have contrib/buildsystems,
> which seems like an earlier attempt at this exact problem?
>
> > But in the meantime, those who are interested in building Git with
> > cmake do not have to wait, doing nothing, I would imagine. I wonder
> > if they can work on a separate project (let's call it git-on-cmake)
> > whose sole purpose is to develop and polish CMakeLists.txt, waiting
> > for an advanced enough version of cmake becomes commonplace. Then,
> > anybody who are interested and has recent cmake can subtree-merge
> > git-on-cmake project into their own clone of our project somewhere,
> > and help developing git-on-cmake further.
>
> I think there's actually a good reason to have it in your tree: people
> use your tree as the basis to build (and submit!) changes.
>
> I noticed the same thing with trying to play with CI changes. As a
> contributor, yes I _can_ make my CI changes, and then base my branches
> on that. But it gets rather awkward juggling branches that contain some
> changes that should go upstream, and some which should not. And quite a
> bit more difficult if people want to use tools like GitGitGadget to just
> target a PR against git.git and send it to the mailing list.
>
> If it lived in contrib/ that might strike a good balance between making
> it available for people to experiment with, but not having people
> confuse it for the official build system.