Re: [PATCH] BreakingChanges: early adopter option

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sep 26, 2024, 14:16 UTC
Message-ID: <02d7b805-f006-43ca-906e-fe9398b8ec35@gmail.com>
In-Reply-To: <ZvVMNMiyjd4xfHzY@pks.im>

On 26/09/2024 12:57, Patrick Steinhardt wrote:

Show 17 quoted lines

> On Sun, Sep 22, 2024 at 10:51:52AM -0700, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>> Junio C Hamano <gitster@pobox.com> 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.

We should be able to make sure those dashed builtins fail though, while that isn't exactly the same as the command not existing it would signal that the command does not work in git3.

> That makes me personally lean into the direction fo making this a build
> time knob.

That's certainly easier to implement.

> The big downside of course is that we'll have less exposure
> as almost nobody ever would build their Git in such a way.

Yes, it's hard to see many people doing that, though if we're lucky some companies that build their own git will test the git3 build. It's also hard to judge how many people would turn on the config option - if we go with that route we could be doing (a lot?) of extra work for not much benefit.

I remember the 1.0 to 2.0 transition as a user. I recall seeing advice massages describing the upcoming changes to "git add -u" and push.default before the 2.0 release. We should check if any of the proposed changes for 3.0 would benefit from something similar.

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

Indeed

Best Wishes

Phillip