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

[Angel Ezquerra]

On Fri, Sep 30, 2011 at 11:47 PM, Angel Ezquerra
<angel.ezquerra at gmail.com> wrote:
>
> 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?

I just checked the online git man page and it seems that the
--new-branch flag does not really make sense for git, since you must
always specify a branch to push.

The push method of the gitsubrepo class in subrepo.py always pushes
the current git branch. I wonder if this means that mercurial will
never push work done on other (non current) branches? Could it be that
push may not push git revisions on other branches, eve if they are
referenced by older revisions of the parent mercurial repo?

I really don't know anything about git so this may not be a problem.
I'd be great if somebody that knew git could confirm that there is no
issue...

Anyway, I don't really know how to move forward with this patch.
Should I add the --ssh option to the list of options passed down to
subrepos? Should I add a --subrepo option instead?

Angel