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