On Mon, Apr 27, 2020 at 3:12 PM Jeff King <peff@xxxxxxxx> wrote: > > 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. Maybe we could move configure.ac and config.mak.in into contrib as well?
