[PATCH 5 of 7 path-configs] ui.paths: obtain paths from [path x] sections

[Gregory Szorc]

On Mon, Feb 9, 2015 at 3:07 PM, Augie Fackler <raf at durin42.com> wrote:

> On Sat, Feb 07, 2015 at 05:13:41PM -0800, Gregory Szorc wrote:
> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1423346419 28800
> > #      Sat Feb 07 14:00:19 2015 -0800
> > # Node ID 8070ddf4999636a5bb52ffa6bfaca69299d86006
> > # Parent  e93fb90e9b87879402147a2fdff2a937087639ca
> > ui.paths: obtain paths from [path x] sections
>
> I'm not remembering any existing cases where we have pseudo-dynamic
> sections like this. It'd be more like merge-tools and auth to do something
> like
>
> [paths]
> default = foo
> default.pushurl = bar
> default.ponies = no
>
> (etc)
>
> I'm not sure how you feel about that. Heck, I'm not sure how I feel
> about it. One advantage is that it grows somewhat naturally from the
> existing paths section.
>
> Overall, I like the idea. I definitely think something like this would
> be handy, but we'll want to be careful about the overall UI
> complexity.
>

I view this particular difference as cosmetic only and thus I have no
strong adversarial opinion. Actually, I think this approach is arguably
better because you can override things via --config (defining spaces inside
--config is a bit awkward). The flip side is that separate sections are
likely easier to read and maintain, since [section] is visually easier for
humans to parse, IMO.

I'll be happy to paint this bikeshed whatever color is needed to see
path-specific configs land in core.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150209/080e9566/attachment.html>