[POLL] Mass renaming options for consistency + guidelines

Yuya Nishihara yuya at tcha.org
Wed Nov 22 08:26:34 EST 2017


On Tue, 21 Nov 2017 16:34:20 +0100, Boris Feld wrote:
> On Tue, 2017-11-21 at 22:00 +0900, Yuya Nishihara wrote:
> > On Sun, 19 Nov 2017 05:13:49 +0000, Martin von Zweigbergk wrote:
> > > On Sat, Nov 18, 2017, 19:22 Yuya Nishihara <yuya at tcha.org> wrote:
> > > > On Mon, 13 Nov 2017 22:31:38 +0900, Yuya Nishihara wrote:
> > > > > FWIW, introducing bunch of permanent aliases might not be as
> > > > > simple as it
> > > > > sounds. It will basically add another axis to the current
> > > > > config layer,
> > > > > [global, user, repo] * [oldname, new-name].
> > > > > 
> > > > > Should user's "ui.tweakdefaults" precede global "ui.tweak-
> > > > > defaults" for
> > > > 
> > > > example?
> > > > > Probably it should. Should they both be listed in "hg config"?
> > > > > Maybe,
> > > > 
> > > > but how
> > > > > can we know which is in effect? No idea...
> > > > 
> > > > Any comments on this? With the current alias handling, user
> > > > options may be
> > > > overridden by the global ones if the user is sloppy to keep his
> > > > hgrc up to
> > > > date.
> > > > 
> > > 
> > > I had not realized that it currently works that way. That feels
> > > clearly
> > > wrong to me.
> > > 
> > > It seems to me like we should resolve the aliases per config file
> > > in an
> > > early phase. So global tweakdefaults gets overridden by global
> > > tweak-defaults. User tweakdefaults gets overridden by user tweak-
> > > defaults.
> > > Then the user value overrides the global value as usual.
> > 
> > Yeah, that would be doable and I think is the only way to get around
> > the issue
> > without a large refactoring of ui object. One drawback is "hg config"
> > output
> > could be a bit surprising, e.g. only normalized names displayed, no
> > item matches
> > for "hg config OLD-NAME-OR-SECTION".
> 
> That cannot be done at config reading time as extensions can register
> and update config items after the config is read.

Good catch.

> Looks like we need to teach the config logic about the hierarchy to
> retrieve the right value.

That reminds me of the ui/config layering series Jun sent before.


More information about the Mercurial-devel mailing list