[PATCH [RFC]] push: propagate --new_branch option when pushing subrepos
Matt Mackall
mpm at selenic.com
Fri Sep 30 13:55:58 CDT 2011
On Fri, 2011-09-30 at 14:32 +0200, Angel Ezquerra wrote:
> 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...
Have you given any thought to which options should apply to git
subrepos?
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list