[PATCH] ui: support declaring repositories in [remotes] section

[Gregory Szorc]

> On Nov 14, 2015, at 22:51, Yuya Nishihara <yuya at tcha.org> wrote:
> 
>> On Sat, 14 Nov 2015 19:38:55 -0800, Sean Farley wrote:
>> 
>> Gregory Szorc <gregory.szorc at gmail.com> writes:
>> 
>>>> On Nov 14, 2015, at 19:08, Sean Farley <sean at farley.io> wrote:
>>>> 
>>>> 
>>>> Gregory Szorc <gregory.szorc at gmail.com> writes:
>>>> 
>>>>> # HG changeset patch
>>>>> # User Gregory Szorc <gregory.szorc at gmail.com>
>>>>> # Date 1447395178 28800
>>>>> #      Thu Nov 12 22:12:58 2015 -0800
>>>>> # Node ID eeed46507676c60df3febc358b5d301ed4470855
>>>>> # Parent  3309714ded262f1bb3e32dd552b01d6926de06d5
>>>>> ui: support declaring repositories in [remotes] section
>>>>> 
>>>>> Power users often want to apply per-path configuration options. For
>>>>> example, they may want to declare an alternate URL for push operations
>>>>> or declare a revset of revisions to push when `hg push` is used
>>>>> (as opposed to attempting to push all revisions by default).
>>>>> 
>>>>> This patch establishes the [remotes] section (bikeshedding invited).
>>>>> Unlike the [paths] sections, the [remotes] section reserves options
>>>>> with "." in them for declaring per-path/remote attributes. (The
>>>>> [paths] section interprets options with "." as a valid alias and
>>>>> attempting to shoehorn "." attribute interpretation into [paths]
>>>>> runs the risk of ambiguous behavior when a user defined an alias
>>>>> with "." that happens to conflict with an attribute defining
>>>>> special behavior. So, a dedicated section with different parsing
>>>>> semantics is necessary to avoid ambiguity.)
>>>>> 
>>>>> Initially, we only support the "pushurl" per-path attribute. However,
>>>>> additional attributes can be added relatively easily.
>>>>> 
>>>>> This patch requires that location values are URLs and that the URLs
>>>>> don't contain #fragment parts. The URL requirement might be
>>>>> controversial. I'm implementing it to see what people say. If people
>>>>> don't like it, I can remove it with little objection. However, I would
>>>>> encourage people to read the location interpretation logic in
>>>>> ui.path.__init__ and commands.push before rushing to judgement. The
>>>>> code and behavior is a bit complicated and requiring URLs does reduce
>>>>> ambiguity over how values should be interpretted. The banning of
>>>>> #fragment from locations should hopefully be less controversial. As
>>>>> a refresher, these declare the default branch to push to. Since
>>>>> branches aren't as popular as they once were, I'm guessing few will
>>>>> miss this feature. Plus, I intend to introduce a "pushrev" or
>>>>> "defaultpushrev" per-path attribute that declares a revset to be used
>>>>> to select what will be pushed when no -r argument is given to
>>>>> `hg push`. This feature will restore the capabilities of #fragment
>>>>> in the URL but will be more powerful and more useful.
>>>>> 
>>>>> In the spirit of full disclosure, I believe mpm had signed off on
>>>>> [urls] for the new section name. However, there has since been some
>>>>> discussion on introducing "remote" "refs" into core. I'm not sure
>>>>> what the user-facing nomenclature for that is going to be. But if it
>>>>> is "remotes", then IMO the section for declaring repos should be
>>>>> [remotes], as implemented in this patch.
>>>>> 
>>>>> diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
>>>>> --- a/mercurial/help/config.txt
>>>>> +++ b/mercurial/help/config.txt
>>>>> @@ -1149,8 +1149,9 @@ used from the command line. Example::
>>>>> To push to the path defined in ``my_path`` run the command::
>>>>> 
>>>>>    hg push my_path
>>>>> 
>>>>> +(See ``[remotes]`` for a more advanced method of declaring repositories.)
>>>>> 
>>>>> ``phases``
>>>>> ----------
>>>>> 
>>>>> @@ -1283,8 +1284,30 @@ have a definite end point.
>>>>> 
>>>>> ``assume-tty``
>>>>>    If true, ALWAYS show a progress bar, unless disable is given.
>>>>> 
>>>>> +``remotes``
>>>>> +-----------
>>>>> +
>>>>> +Declare symbolic names to remote repositories along with additional attributes
>>>>> +defining behavior.
>>>>> +
>>>>> +Options without "." declare the symbolic name of a repository and its location.
>>>>> +Options with "." declare attributes for a repository. For example::
>>>>> +
>>>>> +    [remotes]
>>>>> +    my_remote = https://example.com/repo
>>>>> +    my_remote.pushurl = ssh://example.com/repo
>>>>> +
>>>>> +The followeing per-entry attributes are recognized:
>>>>> +
>>>>> +``pushurl``
>>>>> +    The URL to use for push operations. If not defined, the location defined
>>>>> +    by the attribute-less config option is used.
>>>>> +
>>>>> +(See ``[paths]`` for a simpler but less powerful method to declare symbolic
>>>>> +names to repositories.)
>>>> 
>>>> I really hate another config section for something that is still
>>>> [paths]. The BC complaint seems to be splitting on '.' but we aren't
>>>> going to use any TLDs for our actions (are we?). So, can't we just split
>>>> on '.pushurl'?
>>>> 
>>>> For example,
>>>> 
>>>> [paths]
>>>> smf.io = URL1
>>>> smf.io.pushurl = URL2
>>>> smf.io.pushrev = '.'
>>>> 
>>>> In this case, we can easily split on '.pushurl' and 'pushrev' without
>>>> any ambiguity.
>>> 
>>> I can't predict the future and can't guarantee we won't introduce per-path
>>> attributes that have sub-attributes. E.g. smf.bookmarkmap.@ = upstream
>>> 
>>> (Probably not a good example because of remotenames. But hopefully it gets
>>> my point across that splitting on "." can be ambiguous.)
>>> 
>>> Also, this isn't about domains /TLDs having the naming conflict: it's about
>>> the aliases people choose.
>> 
>> I still don't see how splitting from the left wouldn't be safe enough. I
>> guess you're saying that someone could have '.pushurl' alias. I don't
>> agree that that's enough to warrant a new section and would rather
>> improve what we have.
> 
> I didn't read everything, but there were long discussion. It isn't safe if
> you have "smf" and "smf.io" in paths, and if we introduce ".io" attribute
> in future version. Every single new attribute could be a BC.
> 
> http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/76859
> 
> Anyway, if we want to put everything in "[paths]", can we use a different
> separator such as ":" ? It didn't work until 3.6, so nobody would use "foo:bar"
> aliases.
> 
>  [paths]
>  smf.io = URL1
>  smf.io:pushurl = URL2

Ooh - that's tempting.

I'll wait for mpm or another committer to weigh in before changing anything.