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

Angel Ezquerra angel.ezquerra at gmail.com
Fri Sep 30 07:32:50 CDT 2011


On Fri, Sep 30, 2011 at 9:59 AM, Martin Geisler <mg at aragost.com> wrote:
> 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

As I said I'd like to send  revised patch. Do you guys think that
adding a --subrepo flaw is a good idea? Otherwise I can add the --ssh
option to the list of options that are automatically passed down to
subrepos if you guys think that makes sense, and leave the --remotecmd
and --insecure parameters alone for the time being...

Angel


More information about the Mercurial-devel mailing list