Re: jn/experimental-opts-into-proto-v2, was Re: What's cooking in git.git (May 2020, #09; Tue, 26)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 27, 2020, 20:05 UTC
Message-ID: <nycvar.QRO.7.76.6.2005272159570.56@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqeer46g9l.fsf@gitster.c.googlers.com>

Hi Junio,

On Wed, 27 May 2020, Junio C Hamano wrote:

Show 14 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> >> I have been wondering about the same thing, and if it were not using
> >> its own custom way to read the configuration, it would have been a
> >> non-brainer to merge it down before the release.
> >
> > Hm, do you have more detail about this?  git_config_get_bool feels
> > very standard and non-custom.
> >
> > Do you mean that you would like it to go in repo-settings.c?
>
> No.  I fully accept your reasoning in the proposed log message why a
> handcrafted query to the config system is done in the location the
> patch adds a call.

Now, I apologize. I had not reviewed the patch, and only just read it.

I agree that it is a bit unfortunate that it uses such a non-standard way that hard-codes "feature.experimental" in a different place than repo-settings.c.

And I have to admit that the `git ls-remote` example does not really convince me that it makes sense to go a different route than all other experimental options. It makes it unnecessarily hard to gather the list of features enabled via `features.experimental = true`.

Had it been a patch to repo-settings.c, I would now have tried to lobby for including it into v2.27.0, but as it is, I fully agree with your reasoning to just leave it out.

Ciao, Dscho