Patchwork [V2] subrepo: append subrepo path to subrepo push error messages

login
register
mail settings
Submitter Angel Ezquerra
Date Dec. 16, 2012, 12:29 a.m.
Message ID <cec32425a026c4aeb9a6.1355617752@Lucia-PC>
Download mbox | patch
Permalink /patch/120/
State Accepted
Headers show

Comments

Angel Ezquerra - Dec. 16, 2012, 12:29 a.m.
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra at gmail.com>
# Date 1355438273 -3600
# Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
# Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
subrepo: append subrepo path to subrepo push error messages

This change appends the subrepo path to subrepo push errors. That is, when there
is an error pushing a subrepo, rather than displaying:

pushing subrepo MYSUBREPO to PATH
searching for changes
abort: push creates new remote head HEADHASH!
hint: did you forget to merge? use push -f to force

mercurial will show:

pushing subrepo MYSUBREPO to PATH
searching for changes
abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
hint: did you forget to merge? use push -f to force

The rationale for this change is that the current error messages make it hard
for TortoiseHg (and similar tools) to tell the user which subrepo caused the
push failure.

Note that I have also updated test-subrepo.t to reflect this change. The test
passes on windows.
Mads Kiilerich - Dec. 16, 2012, 1:57 a.m.
Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
> # HG changeset patch
> # User Angel Ezquerra <angel.ezquerra at gmail.com>
> # Date 1355438273 -3600
> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
> subrepo: append subrepo path to subrepo push error messages
>
> This change appends the subrepo path to subrepo push errors. That is, when there
> is an error pushing a subrepo, rather than displaying:
>
> pushing subrepo MYSUBREPO to PATH
> searching for changes
> abort: push creates new remote head HEADHASH!
> hint: did you forget to merge? use push -f to force
>
> mercurial will show:
>
> pushing subrepo MYSUBREPO to PATH
> searching for changes
> abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
> hint: did you forget to merge? use push -f to force
>
> The rationale for this change is that the current error messages make it hard
> for TortoiseHg (and similar tools) to tell the user which subrepo caused the
> push failure.
>
> Note that I have also updated test-subrepo.t to reflect this change. The test
> passes on windows.
>
> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
> --- a/mercurial/subrepo.py
> +++ b/mercurial/subrepo.py
> @@ -567,7 +567,12 @@
>           self._repo.ui.status(_('pushing subrepo %s to %s\n') %
>               (subrelpath(self), dsturl))
>           other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
> -        return self._repo.push(other, force, newbranch=newbranch)
> +        try:
> +            res = self._repo.push(other, force, newbranch=newbranch)
> +        except error.Abort, ex:
> +            errormsg = ex.message + (' (on subrepo %s)' % subrelpath(self))

The message should be marked up for localization.

I also wonder ... I assume a lot of other commands and exceptions from 
subrepo handling have the same issue. They should perhaps be solved 
while we are at it and with the same method. A decorator could perhaps 
be such a more generic method.decorator.

Or is push more important than other commands, making this the only fix 
of this kind that is necessary?

/Mads

/Mads
Angel Ezquerra - Dec. 16, 2012, 10:43 p.m.
On Sun, Dec 16, 2012 at 2:57 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
>
>> # HG changeset patch
>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>> # Date 1355438273 -3600
>> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
>> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
>> subrepo: append subrepo path to subrepo push error messages
>>
>> This change appends the subrepo path to subrepo push errors. That is, when
>> there
>> is an error pushing a subrepo, rather than displaying:
>>
>> pushing subrepo MYSUBREPO to PATH
>> searching for changes
>> abort: push creates new remote head HEADHASH!
>> hint: did you forget to merge? use push -f to force
>>
>> mercurial will show:
>>
>> pushing subrepo MYSUBREPO to PATH
>> searching for changes
>> abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
>> hint: did you forget to merge? use push -f to force
>>
>> The rationale for this change is that the current error messages make it
>> hard
>> for TortoiseHg (and similar tools) to tell the user which subrepo caused
>> the
>> push failure.
>>
>> Note that I have also updated test-subrepo.t to reflect this change. The
>> test
>> passes on windows.
>>
>> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
>> --- a/mercurial/subrepo.py
>> +++ b/mercurial/subrepo.py
>> @@ -567,7 +567,12 @@
>>           self._repo.ui.status(_('pushing subrepo %s to %s\n') %
>>               (subrelpath(self), dsturl))
>>           other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
>> -        return self._repo.push(other, force, newbranch=newbranch)
>> +        try:
>> +            res = self._repo.push(other, force, newbranch=newbranch)
>> +        except error.Abort, ex:
>> +            errormsg = ex.message + (' (on subrepo %s)' %
>> subrelpath(self))
>
>
> The message should be marked up for localization.

You are right. I believe that it would not be enough to put a "_" call
around the ' (on subrepo %s)' string, because it would not be found,
right? Instead I must do:

    errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))

Is that correct?

> I also wonder ... I assume a lot of other commands and exceptions from
> subrepo handling have the same issue. They should perhaps be solved while we
> are at it and with the same method. A decorator could perhaps be such a more
> generic method.decorator.
>
> Or is push more important than other commands, making this the only fix of
> this kind that is necessary?

I think push is more important in the sense that it is (in my
experience) the command that most commonly fails. That being said
probably most (if not all) other commands could benefit from this. I
decided to send this simple patch that fixes the main problem but if
you guys agree I can try to do the same for other commands.

As for using a decorator, are you thinking of something like this?:

def handlessubrepoerror(func):
    def decoratedmethod(self, *args, **kargs):
        try:
            res = func(self, *args, **kargs)
        except error.Abort, ex:
            errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
            raise util.Abort(errormsg, hint=ex.hint)
        return res
    return decoratedmethod

If so, would we need to decorate every method on all the subrepo
subclasses? Maybe there is a simpler way to apply such a generator to
all methods? Also, I worry that adding ' (on subrepo %s)' to every
error message may result on weird error messages? Maybe it should be
changed to '(error happened on subrepo %s)' or something of the sort?

Cheers,

Angel
Angel Ezquerra - Dec. 16, 2012, 10:47 p.m.
On Sun, Dec 16, 2012 at 11:43 PM, Angel Ezquerra
<angel.ezquerra at gmail.com> wrote:
> On Sun, Dec 16, 2012 at 2:57 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
>>
>>> # HG changeset patch
>>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>>> # Date 1355438273 -3600
>>> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
>>> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
>>> subrepo: append subrepo path to subrepo push error messages
>>>
>>> This change appends the subrepo path to subrepo push errors. That is, when
>>> there
>>> is an error pushing a subrepo, rather than displaying:
>>>
>>> pushing subrepo MYSUBREPO to PATH
>>> searching for changes
>>> abort: push creates new remote head HEADHASH!
>>> hint: did you forget to merge? use push -f to force
>>>
>>> mercurial will show:
>>>
>>> pushing subrepo MYSUBREPO to PATH
>>> searching for changes
>>> abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
>>> hint: did you forget to merge? use push -f to force
>>>
>>> The rationale for this change is that the current error messages make it
>>> hard
>>> for TortoiseHg (and similar tools) to tell the user which subrepo caused
>>> the
>>> push failure.
>>>
>>> Note that I have also updated test-subrepo.t to reflect this change. The
>>> test
>>> passes on windows.
>>>
>>> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
>>> --- a/mercurial/subrepo.py
>>> +++ b/mercurial/subrepo.py
>>> @@ -567,7 +567,12 @@
>>>           self._repo.ui.status(_('pushing subrepo %s to %s\n') %
>>>               (subrelpath(self), dsturl))
>>>           other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
>>> -        return self._repo.push(other, force, newbranch=newbranch)
>>> +        try:
>>> +            res = self._repo.push(other, force, newbranch=newbranch)
>>> +        except error.Abort, ex:
>>> +            errormsg = ex.message + (' (on subrepo %s)' %
>>> subrelpath(self))
>>
>>
>> The message should be marked up for localization.
>
> You are right. I believe that it would not be enough to put a "_" call
> around the ' (on subrepo %s)' string, because it would not be found,
> right? Instead I must do:
>
>     errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
>
> Is that correct?
>
>> I also wonder ... I assume a lot of other commands and exceptions from
>> subrepo handling have the same issue. They should perhaps be solved while we
>> are at it and with the same method. A decorator could perhaps be such a more
>> generic method.decorator.
>>
>> Or is push more important than other commands, making this the only fix of
>> this kind that is necessary?
>
> I think push is more important in the sense that it is (in my
> experience) the command that most commonly fails. That being said
> probably most (if not all) other commands could benefit from this. I
> decided to send this simple patch that fixes the main problem but if
> you guys agree I can try to do the same for other commands.
>
> As for using a decorator, are you thinking of something like this?:
>
> def handlessubrepoerror(func):
>     def decoratedmethod(self, *args, **kargs):
>         try:
>             res = func(self, *args, **kargs)
>         except error.Abort, ex:
>             errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
>             raise util.Abort(errormsg, hint=ex.hint)
>         return res
>     return decoratedmethod
>
> If so, would we need to decorate every method on all the subrepo
> subclasses? Maybe there is a simpler way to apply such a generator to
> all methods? Also, I worry that adding ' (on subrepo %s)' to every
> error message may result on weird error messages? Maybe it should be
> changed to '(error happened on subrepo %s)' or something of the sort?
>
> Cheers,
>
> Angel

By the way, should the error message be 'on subrepo' or 'in subrepo'?
The gitsubrepo class has some messages that use 'in subrepo'...

Angel
Mads Kiilerich - Dec. 16, 2012, 11:53 p.m.
Angel Ezquerra wrote, On 12/16/2012 11:43 PM:
> On Sun, Dec 16, 2012 at 2:57 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
>>
>>> # HG changeset patch
>>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>>> # Date 1355438273 -3600
>>> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
>>> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
>>> subrepo: append subrepo path to subrepo push error messages
>>>
>>> This change appends the subrepo path to subrepo push errors. That is, when
>>> there
>>> is an error pushing a subrepo, rather than displaying:
>>>
>>> pushing subrepo MYSUBREPO to PATH
>>> searching for changes
>>> abort: push creates new remote head HEADHASH!
>>> hint: did you forget to merge? use push -f to force
>>>
>>> mercurial will show:
>>>
>>> pushing subrepo MYSUBREPO to PATH
>>> searching for changes
>>> abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
>>> hint: did you forget to merge? use push -f to force
>>>
>>> The rationale for this change is that the current error messages make it
>>> hard
>>> for TortoiseHg (and similar tools) to tell the user which subrepo caused
>>> the
>>> push failure.
>>>
>>> Note that I have also updated test-subrepo.t to reflect this change. The
>>> test
>>> passes on windows.
>>>
>>> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
>>> --- a/mercurial/subrepo.py
>>> +++ b/mercurial/subrepo.py
>>> @@ -567,7 +567,12 @@
>>>            self._repo.ui.status(_('pushing subrepo %s to %s\n') %
>>>                (subrelpath(self), dsturl))
>>>            other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
>>> -        return self._repo.push(other, force, newbranch=newbranch)
>>> +        try:
>>> +            res = self._repo.push(other, force, newbranch=newbranch)
>>> +        except error.Abort, ex:
>>> +            errormsg = ex.message + (' (on subrepo %s)' %
>>> subrelpath(self))
>>
>> The message should be marked up for localization.
> You are right. I believe that it would not be enough to put a "_" call
> around the ' (on subrepo %s)' string, because it would not be found,
> right? Instead I must do:
>
>      errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
>
> Is that correct?

No. _() will be found and the message extracted almost no matter where 
you hide it. You can test with
   xgettext mercurial/subrepo.py
and look at messages.po

> I think push is more important in the sense that it is (in my
> experience) the command that most commonly fails. That being said
> probably most (if not all) other commands could benefit from this. I
> decided to send this simple patch that fixes the main problem but if
> you guys agree I can try to do the same for other commands.
>
> As for using a decorator, are you thinking of something like this?:
>
> def handlessubrepoerror(func):
>      def decoratedmethod(self, *args, **kargs):
>          try:
>              res = func(self, *args, **kargs)
>          except error.Abort, ex:
>              errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
>              raise util.Abort(errormsg, hint=ex.hint)
>          return res
>      return decoratedmethod
>
> If so, would we need to decorate every method on all the subrepo
> subclasses?

Yes, something like that. But it would perhaps be overkill.

> Maybe there is a simpler way to apply such a generator to
> all methods?

Some fancy meta class programming could do it ... but it would be very 
magic and probably not a good idea.

> Also, I worry that adding ' (on subrepo %s)' to every
> error message may result on weird error messages? Maybe it should be
> changed to '(error happened on subrepo %s)' or something of the sort?

Keeping it short is probably what matters the most here.

(And it seems like we have a messy 50/50 between "subrepo" and 
"subrepository" in the user facing messages.)

/Mads
Matt Harbison - Dec. 17, 2012, 3:31 a.m.
Angel Ezquerra <angel.ezquerra <at> gmail.com> writes:

> 
> On Sun, Dec 16, 2012 at 2:57 AM, Mads Kiilerich <mads <at> kiilerich.com>
> wrote:
> > Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
> >
> >> # HG changeset patch
> >> # User Angel Ezquerra <angel.ezquerra <at> gmail.com>
> >> # Date 1355438273 -3600
> >> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
> >> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
> >> subrepo: append subrepo path to subrepo push error messages
> >>

[..]
 
> > I also wonder ... I assume a lot of other commands and exceptions from
> > subrepo handling have the same issue. They should perhaps be solved while we
> > are at it and with the same method. A decorator could perhaps be such a more
> > generic method.decorator.
> >
> > Or is push more important than other commands, making this the only fix of
> > this kind that is necessary?
> 
> I think push is more important in the sense that it is (in my
> experience) the command that most commonly fails. That being said
> probably most (if not all) other commands could benefit from this. I
> decided to send this simple patch that fixes the main problem but if
> you guys agree I can try to do the same for other commands.

FWIW, I've run into the push error myself more than once, and also (IIRC) the
default path not found one you fixed in V3.  I don't recall seeing other errors
from subrepos, but I think that it's useful to adjust them as well as long as
they are clear.  (My original concern was that with deeply nested subrepos, the
abort would be caught at each level as the stack unwound, and another 'on
subrepo' appended.  I have no idea why this isn't happening, but it isn't when
there is a repo, subrepo and sub-subrepo anyway).

As far as 'in subrepo' vs 'on', I didn't really notice until you mentioned it,
but in a quick search, it looks like this patch is the only 'on subrepo'
reference (excluding any that may span lines).  localrepo, mq and cmdutil all
use 'in subrepo', along with 6 references in subrepo.py.  'In' probably sounds
slightly better given that the command is traversing down the directory tree.

When trying to test this change with deep subrepos, I ended up with a 'note'
line that I've never seen before:

  $ hg push -R cloned
  pushing to $TESTTMP\main
  pushing subrepo sub1\sub2 to $TESTTMP/sub2
  searching for changes
  note: unsynced remote changes!
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  pushing subrepo sub1 to $TESTTMP/sub1
  searching for changes
  note: unsynced remote changes!
  adding changesets
  adding manifests
  adding file changes

I have no idea what those notes are trying to convey.  But these seem to have
the same context as the aborts prior to this change (i.e. needing to read up
several lines), so maybe there are more messages than just errors that need to
be augmented, and knowing this influences how?  OTOH, there's probably no sane
way for thg to know it has to pull that line out and put it in the infobar, so
it's probably not worth the hassle.

--Matt
Laurens Holst - Dec. 18, 2012, 10:58 a.m.
Op 16-12-12 23:43, Angel Ezquerra schreef:
> On Sun, Dec 16, 2012 at 2:57 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>> Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
>>
>>> # HG changeset patch
>>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>>> # Date 1355438273 -3600
>>> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
>>> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
>>> subrepo: append subrepo path to subrepo push error messages
>>>
>>> This change appends the subrepo path to subrepo push errors. That is, when
>>> there
>>> is an error pushing a subrepo, rather than displaying:
>>>
>>> pushing subrepo MYSUBREPO to PATH
>>> searching for changes
>>> abort: push creates new remote head HEADHASH!
>>> hint: did you forget to merge? use push -f to force
>>>
>>> mercurial will show:
>>>
>>> pushing subrepo MYSUBREPO to PATH
>>> searching for changes
>>> abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
>>> hint: did you forget to merge? use push -f to force
>>>
>>> The rationale for this change is that the current error messages make it
>>> hard
>>> for TortoiseHg (and similar tools) to tell the user which subrepo caused
>>> the
>>> push failure.
>>>
>>> Note that I have also updated test-subrepo.t to reflect this change. The
>>> test
>>> passes on windows.
>>>
>>> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
>>> --- a/mercurial/subrepo.py
>>> +++ b/mercurial/subrepo.py
>>> @@ -567,7 +567,12 @@
>>>            self._repo.ui.status(_('pushing subrepo %s to %s\n') %
>>>                (subrelpath(self), dsturl))
>>>            other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
>>> -        return self._repo.push(other, force, newbranch=newbranch)
>>> +        try:
>>> +            res = self._repo.push(other, force, newbranch=newbranch)
>>> +        except error.Abort, ex:
>>> +            errormsg = ex.message + (' (on subrepo %s)' %
>>> subrelpath(self))
>>
>> The message should be marked up for localization.
> You are right. I believe that it would not be enough to put a "_" call
> around the ' (on subrepo %s)' string, because it would not be found,
> right? Instead I must do:
>
>      errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
>
> Is that correct?

No, it?s should be the other way around:

errormsg = _('%s (on subrepo %s)') % (ex.message, subrelpath(self))

The replacement has to be done outside the localisation call, otherwise 
it will look up "blah (on subrepo x)" in the dictionary and fail to find it.

But using %s to include the message is indeed better than string 
concatenation.

~Laurens
Angel Ezquerra - Dec. 18, 2012, 9:58 p.m.
On Tue, Dec 18, 2012 at 11:58 AM, Laurens Holst <laurens.nospam at grauw.nl> wrote:
> Op 16-12-12 23:43, Angel Ezquerra schreef:
>
>> On Sun, Dec 16, 2012 at 2:57 AM, Mads Kiilerich <mads at kiilerich.com>
>> wrote:
>>>
>>> Angel Ezquerra wrote, On 12/16/2012 01:29 AM:
>>>
>>>> # HG changeset patch
>>>> # User Angel Ezquerra <angel.ezquerra at gmail.com>
>>>> # Date 1355438273 -3600
>>>> # Node ID cec32425a026c4aeb9a6495086b1a1fbe916be24
>>>> # Parent  34a1a639d8358e43f4bcba7b0cff19f4e4e6958d
>>>> subrepo: append subrepo path to subrepo push error messages
>>>>
>>>> This change appends the subrepo path to subrepo push errors. That is,
>>>> when
>>>> there
>>>> is an error pushing a subrepo, rather than displaying:
>>>>
>>>> pushing subrepo MYSUBREPO to PATH
>>>> searching for changes
>>>> abort: push creates new remote head HEADHASH!
>>>> hint: did you forget to merge? use push -f to force
>>>>
>>>> mercurial will show:
>>>>
>>>> pushing subrepo MYSUBREPO to PATH
>>>> searching for changes
>>>> abort: push creates new remote head HEADHASH! (on subrepo MYSUBREPO)
>>>> hint: did you forget to merge? use push -f to force
>>>>
>>>> The rationale for this change is that the current error messages make it
>>>> hard
>>>> for TortoiseHg (and similar tools) to tell the user which subrepo caused
>>>> the
>>>> push failure.
>>>>
>>>> Note that I have also updated test-subrepo.t to reflect this change. The
>>>> test
>>>> passes on windows.
>>>>
>>>> diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
>>>> --- a/mercurial/subrepo.py
>>>> +++ b/mercurial/subrepo.py
>>>> @@ -567,7 +567,12 @@
>>>>            self._repo.ui.status(_('pushing subrepo %s to %s\n') %
>>>>                (subrelpath(self), dsturl))
>>>>            other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
>>>> -        return self._repo.push(other, force, newbranch=newbranch)
>>>> +        try:
>>>> +            res = self._repo.push(other, force, newbranch=newbranch)
>>>> +        except error.Abort, ex:
>>>> +            errormsg = ex.message + (' (on subrepo %s)' %
>>>> subrelpath(self))
>>>
>>>
>>> The message should be marked up for localization.
>>
>> You are right. I believe that it would not be enough to put a "_" call
>> around the ' (on subrepo %s)' string, because it would not be found,
>> right? Instead I must do:
>>
>>      errormsg = _('%s (on subrepo %s)' % (ex.message, subrelpath(self)))
>>
>> Is that correct?
>
>
> No, it?s should be the other way around:
>
> errormsg = _('%s (on subrepo %s)') % (ex.message, subrelpath(self))
>
> The replacement has to be done outside the localisation call, otherwise it
> will look up "blah (on subrepo x)" in the dictionary and fail to find it.
>
> But using %s to include the message is indeed better than string
> concatenation.
>
> ~Laurens
>

Thank you Laurens,

I'll keep that in mind when I make the next version of this patch.

Cheers,

Angel

Patch

diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
--- a/mercurial/subrepo.py
+++ b/mercurial/subrepo.py
@@ -567,7 +567,12 @@ 
         self._repo.ui.status(_('pushing subrepo %s to %s\n') %
             (subrelpath(self), dsturl))
         other = hg.peer(self._repo, {'ssh': ssh}, dsturl)
-        return self._repo.push(other, force, newbranch=newbranch)
+        try:
+            res = self._repo.push(other, force, newbranch=newbranch)
+        except error.Abort, ex:
+            errormsg = ex.message + (' (on subrepo %s)' % subrelpath(self))
+            raise util.Abort(errormsg,  hint=ex.hint)
+        return res
 
     def outgoing(self, ui, dest, opts):
         return hg.outgoing(ui, self._repo, _abssource(self._repo, True), opts)
diff --git a/tests/test-subrepo.t b/tests/test-subrepo.t
--- a/tests/test-subrepo.t
+++ b/tests/test-subrepo.t
@@ -320,7 +320,7 @@ 
   no changes found
   pushing subrepo s to $TESTTMP/t/s (glob)
   searching for changes
-  abort: push creates new remote head 12a213df6fa9!
+  abort: push creates new remote head 12a213df6fa9! (on subrepo s)
   (did you forget to merge? use push -f to force)
   [255]
   $ hg push -f
@@ -587,7 +587,7 @@ 
   created new head
   $ hg -R repo2 ci -m3
   $ hg -q -R repo2 push
-  abort: push creates new remote head cc505f09a8b2!
+  abort: push creates new remote head cc505f09a8b2! (on subrepo s)
   (did you forget to merge? use push -f to force)
   [255]
   $ hg -R repo update