Propagating push arguments to subrepos

[Didly]

On Fri, Sep 30, 2011 at 5:01 AM, Greg Ward <greg-hg at gerg.ca> wrote:
> On Thu, Sep 29, 2011 at 4:57 AM, Didly <didlybom at gmail.com> wrote:
>> Of course that would work, but depending on the number of subrepos it
>> may be a bit unpractical, or may require using the onsub extension,
>> etc. In addition, I believe that push is supposed to only push those
>> subrepo revisions that are used on the top repo (and their ancestors),
>> although I am not 100% that is the case. If it was, it would be quite
>> hard to replicate that behaviour by manually pushing the subrepos.
>>
>> In any case, ignoring the arguments provided to push when pushing
>> subrepos seems quite odd to me. It seems natural to at least have a
>> way to tell hg to use those arguments when pushing subrepos.
>
> But many arguments to push don't make sense for subrepos. The URL? -r?
> --branch and --bookmark may or may not work, depending on your branch
> naming policy and how tightly connected your parent repo and subrepos
> are.
>
> I would say that passing --new-branch makes sense. Maaaaybe --force.
> Most likely --ssh. Possibly --remotecmd, but if you are pushing to
> different servers (ie. using absolute URLs for subrepos), that might
> be a bad idea.

Indeed, that is why I did not pass down all the push parameters on my
patch. Some of them should definitely never be passed down to subrepos
(--rev, --bookmark and --branch), as they are repo specific.

As for the rest of them, it would be best if we could tell mercurial
whether we want it to pass them down to subrepos or not. Perhaps we
could add a --subrepo parameter that controls whether push passes
--new-branch, --insecure, --ssh and --remotecmd to its subrepos?
Ideally --subrepo would also control whether --force is passed down as
well, but I don't know if we can do so since it is already being
passed down and that would change the current behavior of push in a
significant way?

I am willing to rework my patch and send it again with this change if
you guys agree with this change. Otherwise I can simply fix my current
patch to remove the default values for the newbranch parameter.

Angel