[PATCH 1 of 2] config: introduce load order tracking

[Yuya Nishihara]

On Tue, 10 Jul 2018 15:55:36 +0200, Boris FELD wrote:
> On 09/07/2018 14:50, Yuya Nishihara wrote:
> > On Mon, 09 Jul 2018 12:12:21 +0200, Boris Feld wrote:
> >> # HG changeset patch
> >> # User Boris Feld <boris.feld at octobus.net>
> >> # Date 1530887625 -7200
> >> #      Fri Jul 06 16:33:45 2018 +0200
> >> # Node ID 1019d8a4f6b810aaa63651ed56b29668650f590e
> >> # Parent  8c38d29482177cd40243a008057d6762c7d23c6f
> >> # EXP-Topic config-order
> >> # Available At https://bitbucket.org/octobus/mercurial-devel/
> >> #              hg pull https://bitbucket.org/octobus/mercurial-devel/ -r 1019d8a4f6b8
> >> config: introduce load order tracking
> >>
> >> Configuration values reads from disk are now associated with the index of the
> >> file they came from. (First loaded file has index 0, second file index 1,
> >> etc…).
> >>
> >> This will ultimately allow us to use the alias value of a configuration item
> >> if it was defined in a higher priority file than the configuration item value
> >> itself.
> >>
> >> See next changeset for details.
> >>
> >> Value set directly through the code or through the command line have the highest
> >> priority.
> > Didn't read this thoroughly, but have you tried making configs layered (e.g.
> > overlay -> repo -> user -> env -> system)?
> >
> > https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095733.html
> >
> > The previous RFC series seems a bit over engineered, but I think the idea
> > behind it is probably better overall than keep track of the "level" for each
> > item. We can get rid of the "cow" hack, configoverride() can be instant, etc.
> 
> The layered approach seems to be the right architecture but will require 
> more refactoring and careful works to make it right. We would like to 
> favor for the current simpler, hackier, approach and prepare the road to 
> the layered configuration way.

If the problem to be addressed by this hack is important, and if the hack is
really simple, sure I would say go for it. But I, as an old Mercurial user,
see the bulk renaming of the config keys is minor improvement.

Thoughts?