[PATCH [RFC]] push: propagate --new_branch option when pushing subrepos

Martin Geisler mg at aragost.com
Fri Sep 30 02:59:50 CDT 2011


Greg Ward <greg-hg at gerg.ca> writes:

> On Thu, Sep 29, 2011 at 2:26 PM, Martin Geisler <mg at lazybytes.net> wrote:
>>> diff --git a/mercurial/commands.py b/mercurial/commands.py
>>> --- a/mercurial/commands.py
>>> +++ b/mercurial/commands.py
>>> @@ -4077,7 +4077,7 @@
>>>          c = repo['']
>>>          subs = c.substate # only repos that are committed
>>>          for s in sorted(subs):
>>> -            if not c.sub(s).push(opts.get('force')):
>>> +            if not c.sub(s).push(opts.get('force'), opts.get('new_branch')):
>>
>> I think it would make sense to propagate the entire opts dictionary
>> instead. That would be a bigger chance, but it would mean that things
>> like --ssh and --remotecmd are also propagated.
>
> As I just posted because I didn't notice that Angel had sent a patch:
> I disagree! I think it does make sense to construct a new dict of
> options that should propagate, but a blind copy is risky.

Yeah, you're right that some flags really are per-remote-repository and
so shouldn't be used for all subrepos at once. I'm actually thinking
that the --remotecmd flag should always be set in the .hg/hgrc instead
of the command line.

> My take:
>
>   * yes: --new-branch, --ssh
>   * maybe: --force, --remotecmd, --insecure
>   * no way: --rev, --bookmark, --branch

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial-devel mailing list