[PATCH] subrepo: do not push "clean" subrepos when the parent repo is pushed

Matt Harbison matt_harbison at yahoo.com
Thu Feb 14 21:49:29 CST 2013

On Thu, 14 Feb 2013 01:13:44 +0100, Angel Ezquerra wrote:

> On Thu, Feb 14, 2013 at 1:06 AM, Angel Ezquerra
> <angel.ezquerra at gmail.com> wrote:


> This is step one in the plan that Matt, Martin and I discussed to
> improve subrepos during the London sprint.

Is there a brief overview of the plan somewhere?
> I also am working on step two of the plan, which was to add a
> "--subrepos" flag to hg push.

Is this your idea about passing (some?) parameters to subrepos [1]?  If 
so, does 'outgoing' need the same method of filtering the option dict [2] 
for consistency?  (I was a bit surprised that outgoing -S passes along the 
--rev option, which causes it to abort in the subrepo with a (parent) 
hash, or lie or abort if given a rev.)  There's also a couple bugs written 
about --addremove not being passed along, so what to pass or not seems 
like a wider (general?) problem.

FWIW, I've got code that seems to be able to honor the -r flag for 
'outgoing' and 'push' (issue2314) [3], including the case where the parent 
commits an older version of the subrepo after a newer version.  I wasn't 
happy with how I had to hack the option dict after translating --rev, but 
it sounds like you are working in this area anyway.  So I'll try to submit 
this as a (rough) RFC this weekend, and assuming the concept is OK, we 
will probably need to coordinate how options are handed off to subrepos 
for 'push' and 'outgoing'.


[1] http://www.selenic.com/pipermail/mercurial-devel/2011-

[2] http://www.selenic.com/pipermail/mercurial-devel/2011-

[3] http://bz.selenic.com/show_bug.cgi?id=2314

More information about the Mercurial-devel mailing list