On 26/09/2024 12:57, Patrick Steinhardt wrote:
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:
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
