Re: [PATCH] BreakingChanges: early adopter option

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 26, 2024, 15:57 UTC
Message-ID: <xmqqed56mmqf.fsf@gitster.g>
In-Reply-To: <ZvVMNMiyjd4xfHzY@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 14 quoted lines

>> 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.

Show 6 quoted lines

> 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.