[PATCH v3] outgoing: respect ":pushurl" paths (issue5365)

[Hollis Blanchard]

On 12/15/2017 05:15 AM, Yuya Nishihara wrote:
> On Thu, 14 Dec 2017 16:23:24 -0800, Hollis Blanchard wrote:
>> # HG changeset patch
>> # User Hollis Blanchard <hollis_blanchard at mentor.com>
>> # Date 1513292635 28800
>> #      Thu Dec 14 15:03:55 2017 -0800
>> # Node ID a71c6d5ea84933324e0c516ea2e4967e06616c31
>> # Parent  4937db58b663faa6893c51a41cec28114a165dd0
>> outgoing: respect ":pushurl" paths (issue5365)
>> diff --git a/mercurial/hg.py b/mercurial/hg.py
>> --- a/mercurial/hg.py
>> +++ b/mercurial/hg.py
>> @@ -912,8 +912,20 @@ def incoming(ui, repo, source, opts):
>>       return _incoming(display, subreporecurse, ui, repo, source, opts)
>>   
>>   def _outgoing(ui, repo, dest, opts):
>> -    dest = ui.expandpath(dest or 'default-push', dest or 'default')
>> -    dest, branches = parseurl(dest, opts.get('branch'))
>> +    path = None
>> +    try:
>> +        path = ui.paths.getpath(dest, default=('default-push', 'default'))
> Here we need to test "not path" because it may be None.
Oops, thanks.
>> +        dest = path.pushloc or path.loc
>> +        branches = path.branch, opts.get('branch') or []
>> +    except error.RepoError:
>> +        # Fake up empty state to avoid changing the user-facing error message.
>> +        path = dest
>> +        branches = (None, [])
> I think raising RepoError should be fine. The error message isn't wrong.
On IRC, the RepoError's message kicked off a verging-on-religious 
discussion about backwards compatibility.

In the full context of the patch:

  * Original error message: "abort: repository green not found!"
  * New error message: "abort: repository green does not exist!"
  * The error code, which is more likely to be used in scripts than the
    error message, doesn't change.
  * It's more complex to preserve the "not found" message, which is how
    missed the 'not path' case you pointed out above. Less complexity is
    better.

Separately, I noticed that I missed the 'outgoing()' revset predicate, 
so v4 will fix that too. That means extra "error message preservation" 
complexity would be introduced in two places, not just one...

I'll send v4 momentarily.

Hollis Blanchard <hollis_blanchard at mentor.com>
Mentor Graphics Emulation Division

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20171215/fb4ecdb1/attachment.html>