[PATCH 3 of 5 paths v3] ui.paths: filter config options containing "." (BC)

[Matt Mackall]

On Fri, 2015-03-13 at 15:56 -0700, Pierre-Yves David wrote:
> 
> On 03/11/2015 03:55 PM, Matt Mackall wrote:
> > On Tue, 2015-03-10 at 20:56 -0700, Gregory Szorc wrote:
> >> On Mon, Mar 9, 2015 at 8:10 PM, Pierre-Yves David <
> >> pierre-yves.david at ens-lyon.org> wrote:
> >>
> >>>
> >>>
> >>> On 03/08/2015 12:54 PM, Gregory Szorc wrote:
> >>>
> >>>> # HG changeset patch
> >>>> # User Gregory Szorc <gregory.szorc at gmail.com>
> >>>> # Date 1425243224 28800
> >>>> #      Sun Mar 01 12:53:44 2015 -0800
> >>>> # Node ID 0f9c6588afcbaaca41b8a5ff17d8969e7f6d157a
> >>>> # Parent  57681bad997779da88778ff95254951c89250441
> >>>> ui.paths: filter config options containing "." (BC)
> >>>>
> >>>> Upcoming patches will enable additional attributes to be defined
> >>>> on a per-path basis. This will be done by creating config options
> >>>> of the form "path.X" and "path.Y."
> >>>>
> >>>> This patch teaches the new paths API to assume options containing
> >>>> "." are per-path attributes and not valid path names.
> >>>>
> >>>> This patch is technically backwards incompatible because nothing
> >>>> was preventing people from using "." in path names. However, the
> >>>> author feels this convention is not widespread enough to warrant
> >>>> maintaining backwards compatibility. If backwards compatibility
> >>>> is needed, we'll have to employ different functionality for
> >>>> defining per-path attributes, such as separate config sections
> >>>> per path. An earlier version of this patch series did feature
> >>>> separate config sections per path. However, people felt that
> >>>> adopting sub-options was a better approach since this is done
> >>>> elsewhere (such as with merge tool definition).
> >>>>
> >>>
> >>> Sorry to be late to the party, but I feel like this change is, as is, too
> >>> user-hostile. I'm -certain- there is people out there using `foo.bar`
> >>> paths, and just breaking them seems unfortunate.
> >>>
> >>> Can we get something so that `hg push foo.bar` still works if foo.bar
> >>> exists? (possibly with a warning?) If a someone explicitly ask for foo.bar
> >>> there is a good chance this is not an attributes and that we should give
> >>> them what they asked for.
> >>>
> >>> We should probably also lists them in `hg path` if they do not match any
> >>> known attributes. That would reduce script breakage.
> >>
> >>
> >> I can make the case that half-support for `foo.bar` paths is even more
> >> hostile than the proposed clean break.
> >
> > I agree that the odds of people having foo.bar paths is probably 100%:
> > it is after all how DNS names are structured. Unfortunately it's also
> > how our config namespace is structured.
> >
> >> I think a clean, one-time break is better.
> >
> > I greatly prefer zero-time breaks, but I don't have a great alternative
> > suggestion. We do have a bit of precedent in the [auth] section though.
> > Perhaps we can do:
> >
> > [paths]
> > old.style = some/path
> > new.style.path = some/other/pass
> > new.style.option = foo
> > bogus.option = foo
> 
> I'm a bit puzzled by the new.style.path here (I'll change it to 
> `newstyle.path` to clarify my puzzling.)

Then you've 100% missed the point. This idea is all about dots and how
we tell what they mean.

-- 
Mathematics is the supreme nostalgia of our time.