[PATCH] subrepo: do not push "clean" subrepos when the parent repo is pushed
Matt Harbison
matt_harbison at yahoo.com
Fri Feb 15 03:49:29 UTC 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'.
--Matt
[1] http://www.selenic.com/pipermail/mercurial-devel/2011-
September/034435.html
[2] http://www.selenic.com/pipermail/mercurial-devel/2011-
September/034453.html
[3] http://bz.selenic.com/show_bug.cgi?id=2314
More information about the Mercurial-devel
mailing list