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

[Angel Ezquerra]

On Sep 30, 2011 8:56 PM, "Matt Mackall" <mpm at selenic.com> wrote:
>
> 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.
>
>

well, as it is often said in this list I don't really "speak" git, but the
little I know is that it does not have anonymous branches like mercurial.
Thus it seems that the new-branch parameter should be passed down to git.

As for the other parameters I don't really know... In any case I don't even
know what to do with the new-branch param once it gets to the git subrepo
push function...

What do you think of the idea of introducing a --subrepo flag to control
this behavior?

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110930/98674070/attachment.html>