[PATCH RFC] ui: add support for a tweakdefaults knob

Pierre-Yves David pierre-yves.david at ens-lyon.org
Mon Jun 19 11:32:29 EDT 2017



On 06/19/2017 04:58 PM, Yuya Nishihara wrote:
> On Mon, 19 Jun 2017 16:04:41 +0200, Pierre-Yves David wrote:
>>>> There have been talk about such registry of option for quite some time
>>>> (including at the 4.2 central sprint). David Demelier ping me about
>>>> this[1] again 10 days ago and found some time to poke at it yesterday.
>>>>
>>>> It turned out I ended up with something that work, I've started
>>>> patchbombing it[2]. Once this is in, we can update the tweakdefault flag
>>>> to use this.
>>>>
>>>> [1] as part of his quest for
>>>> https://www.mercurial-scm.org/wiki/ConfigConsolidationPlan
>>>> [2]
>>>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-June/099866.html
>>>
>>> These patches look a good move, though I think the config registry idea is
>>> bloated a bit. Suppose we have tons of config items, I don't think it's good
>>> idea to register them per item.
>>
>> I'm not sure what is your concerns here can you elaborate? We have about
>> 200 known config option in core. That seems a manageable number of object.
>
> Sorry, I just felt it's overengineered. I don't have no particular concern
> about speed.
>
>> As centralized config growth feature it will needs one item for each
>> config option anyway (alias, default, documentation, etc...).
>> Do you have an alternative idea in mind?
>
> Hmm. If we want these features, perhaps configitem() function would be the
> best.

I think we want these features. David Demelier (+ at least I) want the 
alias feature for ConfigConsolidationPlan. Gregory Szorc (and others 
including me) wants the documentation features. If someone has concerns 
about these feature we should probably resolves them before pushing 
further forward.

I agree that without the future (more complex) feature, that would be a 
bit heavy (a simple list of 3 tuples would be fine) :-)

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list