Jeff King <peff@xxxxxxxx> writes: > I think what I'm suggesting is not all that different from this, except > that I'd suspect "next" would not get enough exposure. So in my mind > merging to master is not so much "hooray, we now have visual studio > support" but rather the first step in getting data. But we'd have to be > very clear about how the project regards the cmake support: it's there > for now, you're encouraged to play with it, but don't be upset if it > needs some coaxing to behave like the normal Makefile or if it goes away > in the future. I think you said almost everything I would have said. 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. Given the observation in the thread that it would take a fairly recent version to benefit platform-agnostic usability features, I did not get an impression that it is ready to be anywhere near that, not even ready for 'next'. It is *not* like "Sibi's patches were bad but they can become ready with further polishing". The impression I got was that the large part of why it is not ready is because it needs time for larger set of distros to adopt more recent versions of cmake. And I somehow think that rewriting Sibi's patches to lose the parts that takes advantage of more recent cmake (abstracting "mklink" vs "ln" out was mentioned as an example---there may be a lot more) is going in a wrong direction. The world will eventually catch up, and Git does not need cmake immediately. Using the more recent features while waiting for the right time would be a more sensible approach than aiming for an outdated version. So, perhaps we'll try again in 3 years, perhaps, to consider if it makes sense to add the cmake support to _my_ tree. 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. Then we'll meet again in 3 years and see if the world got new enough ;-)
