Hi Junio, On Wed, 27 May 2020, Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> 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
