<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 11, 2015 at 3:55 PM, Matt Mackall <span dir="ltr"><<a href="mailto:mpm@selenic.com" target="_blank">mpm@selenic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree that the odds of people having foo.bar paths is probably 100%:<br>
it is after all how DNS names are structured. Unfortunately it's also<br>
how our config namespace is structured.<span class=""><br></span></blockquote><div><br></div><div>I think it is important to distinguish between option names, option values, and command line arguments.<br><br></div><div>For option values and command line arguments, absolutely we'll have periods because of hostnames. However, I believe our logic there is to first attempt to parse those values as URLs, then fall back to a filesystem-local path if a scheme isn't present. (Follow-up idea: have Mercurial store URLs in more situations because bare strings are more ambiguous.)<br></div><div><br></div><div>If we limit discussion to option values, I'm still not convinced supporting periods is important.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I think a clean, one-time break is better.<br>
<br>
</span>I greatly prefer zero-time breaks, but I don't have a great alternative<br>
suggestion. We do have a bit of precedent in the [auth] section though.<br>
Perhaps we can do:<br>
<br>
[paths]<br>
old.style = some/path<br>
new.style.path = some/other/pass<br>
new.style.option = foo<br>
bogus.option = foo<br>
<br>
Here, hg paths would list:<br>
<br>
old.style<br>
new.style<br>
bogus.option<br>
<br>
(..and we'd also change clone to make the default path setting<br>
"default.path".)<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>This is an interesting idea. I like how it avoids ambiguity between whether an entry is a path or isn't. However, it still has concerns:<br><br></div><div>* Long-term Mercurial users now have to convert to a new config style to use advanced options.<br></div><div>* Potential for collision between user-defined path names and per-path options.<br><br></div><div>I imagine a user will see they can add ".pushrev" to a path and produce a snippet like:<br><br></div><div>[paths]<br></div><div>central = <a href="https://hg.mozilla.org/mozilla-central">https://hg.mozilla.org/mozilla-central</a><br></div><div>central.pushrev = .<br><br></div><div>Without the ".path", this situation is ambiguous. Do we then have to examine common option prefixes and do some kind of disambiguation to figure out the user's intent? What about something like this:<br><br></div><div>[paths]<br></div><div>repo.prod = <a href="https://prod.hg.example.com/repo">https://prod.hg.example.com/repo</a><br></div><div>repo.prod.pushrev = .<br></div><div>repo.dev = <a href="https://dev.hg.example.com/repo">https://dev.hg.example.com/repo</a><br></div><br></div><div class="gmail_quote">I still think unsupported periods in path names is looking pretty reasonable. So does separate [path.x] sections.<br></div></div></div>