On Sun, Sep 22, 2024 at 10:51:52AM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > >> Discussing the desire to make breaking changes, declaring that > >> breaking changes are made at a certain version boundary, and > >> recording these decisions in this document, are necessary but not > >> sufficient. We need to make sure that we can implement, test, and > >> deploy such impactful changes. > >> > >> Formalize the mechanism based on the `feature.*` configuration > >> variable to allow early adopters to opt into the breaking change in > >> a version of Git before the planned version for the breaking change. > >> ... > > ... to see what it involves > > to allow early adopters to experience Git 3.0 features/removals > > before it actually happens. Thanks for putting together this document! We also had this discussion during the contributor's summit, and I certainly agree that having such a toggle makes a ton of sense. > Sorry for a long monologue on this important topic, while everybody > is away. Hopefully we'll see more comments when they get back once > the week starts ;-) > > > Switching behaviour at runtime with feature.git3 should work well, > > and we can also add tests that checks the new behaviour by doing > > "test_config feature.git3 true". > > ... > > If we are willing to burden early adopters a bit more, we could make > > it a build-time option. With "make GIT_BUILD_FOR_GIT3=YesPlease", > > binaries will be built for all the then-current Git 3.0 features and > > documentation under development. It certainly is a simpler-to-build > > option that is easier for us, but I am not sure if that is acceptable > > by those who volunteer to test the upcoming big version. > > > > One thing to note is that depending on the nature of a change, once > > you start using a feature only available in a newer version of Git > > in your repository, the resulting repository may not be understood > > by an older version of Git... > > While I still am with the position that we can do this either at > runtime or at build time, with the trade-off being that it is more > costly for developers to do it at runtime and more cumbersome for > early adopters to do it at build time, I realize that the last point > above is unrelated. If one or some of the features behind either > feature.git3 runtime option or GIT_BUILD_FOR_GIT3 build-time option > makes a repository inaccessible to versions of Git without these > features, we have the extension.* mechanism to make sure nothing > breaks, and testing that such a Git3 feature is properly protected > by the extension.* mechanism is part of the early adopter testing. > > 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. 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. Patrick
