Patrick Steinhardt <ps@xxxxxx> writes: >> How much more costly to do at runtime is still subject to further >> analysis, I think. I know that it means we need to build and >> install the docs twice to support "git -c feature.git3=on help", for >> example, but I am not sure what the best way to use CI would be >> (write tests that check features with different behaviour by >> explicitly running them with "git -c feature.git3=on"? Run the same >> set of tests in a separate job that has "[feature] git3" in its >> $HOME/.gitconfig?). > > One problem with runtime toggles are commands that go away entirely. We > can of course hide them away in various different places and make it > impossible to call them. But one of the downsides is that it is not > "true" to the actual removal, as for example the dashed builtins may > still exist. Yes, as I said, such a change to various infrastructure that are not specific to Git 3.0 boundary (e.g. run_builtin() dispatch needs to tell which new commands are from the future and hide them unless configured) is costly but reusable once written. A new or removed command that is not a built-in is even harder to manage at runtime. > That makes me personally lean into the direction fo making this a build > time knob. The big downside of course is that we'll have less exposure > as almost nobody ever would build their Git in such a way. But the big > upside is that we end up executing the code exactly as it would look > like if it were removed, so the coverage we get e.g. both from Git devs > and from our CI would be much more telling. Sad but I tend to agree.
