I split up the previously merged to "next" ab/cmake-nix-and-ci and submitted the uncontroversial parts of it as: https://lore.kernel.org/git/patch-1.1-0fa41115261-20221219T102205Z-avarab@xxxxxxxxx https://lore.kernel.org/git/cover-0.2-00000000000-20221219T102813Z-avarab@xxxxxxxxx https://lore.kernel.org/git/cover-0.6-00000000000-20221219T183623Z-avarab@xxxxxxxxx I think whatever happens with js/ci-disable-cmake-by-default that it makes sense to pick up & integrate those. It's all narrow fixes for specific issues, none of which cover the area(s) that caused ab/cmake-nix-and-ci to be ejected from "next". On Mon, Dec 26 2022, Junio C Hamano wrote: > * js/ci-disable-cmake-by-default (2022-12-20) 1 commit > - ci: only run win+VS build & tests in Git for Windows' fork > > Stop running win+VS build by default. > > Will merge to 'next'? > source: <pull.1445.git.1671461414191.gitgitgadget@xxxxxxxxx> Per my feedback there, I still think it would make sense to at least split up the "should we build with MSVC?" from the "do we use cmake, and run the re-run tests we already ran with GCC with MSVC too?". But I understand that Johannes disagreed with that, and didn't think testing MSVC in addition to GCC & Clang was valuable. What I'd like clarification on if this moves forward is what the status of cmake in the tree is. The reason I submitted ab/cmake-nix-and-ci was to make testing cmake+ctest on *nix trivial, so that if I and others made Makefile changes we could change & test the cmake recipe as well. But now we won't even run that in CI, and "git-for-windows" will have ownership of it. Does that mean that for such Makefile changes we should simply leave out the cmake changes, and rely on git-for-windows to "catch up" with its cmake contrib component? Ultimately I don't mind such an arrangement, but I think that js/ci-disable-cmake-by-default brings us to a weird in-between state. Just removing it from the tree and having git-for-windows carry it would make sense. So would IMO taking ab/cmake-nix-and-ci (or the restart of it above), i.e. to have cmake fixes accepted in git/git. But now we're moving to a state where such patches aren't welcome, but we'll still carry inevitably bitrotting code in-tree, which we're intentionally not testing anymore until it's merged to git-for-windows? Thanks.
