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

Matt Harbison matt_harbison at yahoo.com
Sun Dec 16 21:31:38 CST 2012


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






More information about the Mercurial-devel mailing list