"submit" command naming - just "bundle" preferred?

[Martin Pool]

On 7/19/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Ian Clatworthy wrote:
> > Aaron Bentley wrote:
> >> Ian Clatworthy wrote:
> >>> Aaron Bentley wrote:
> >>> I've been a little uneasy about introducing 'submit' as a new command
> >>> name for a few weeks now. I haven't spoken up because I didn't have a
> >>> better alternative, I hoped someone else would, and I had other things I
> >>> needed to get done first. My concern boils down to this: we aren't
> >>> actually submitting anything - we're just preparing something to submit.
> >> In this version, yes.  I expect that it will be able to send email in
> >> the future.
> >
> > Do you see sending being the default in the future?
>
> I'm not sure.  We may use "send" for that.

It's a good question.  It seems to me that producing a bundle is kind of
an implementation detail - when I do this, it's almost always because I'm
going to send it, and it's just an implementation limit that we don't
nicely invoke the mail client yet.  On the other hand it's nice to expose
small composable operations so people can make up new things.

> >> But "submit -r -3..-2" does not behave the same as "bundle -3..-2", and
> >> "submit --no-bundle" has no analogue in the bundle command.  I think
> >> that "bzr bundle --no-bundle" is ludicrous, but the option name is
> >> accurate-- it's the command name that's wrong.
> >
> > Fair enough. Depending on the default question above though, we could
> > get "submit --no-submit" instead maybe. :-)
>
> I think it would be "submit --no-mail", or "submit --no-send".

How about

  send -o OUTPUTFILE

> > It's a shame that "delta", "changes" and the like are all nouns because
> > I really do want a verb but those words kind of better fit my mental
> > model of this use case: (always) generate an intelligent changeset and
> > (optionally) send it off somewhere.
>
> The most descriptive thing I've come up with is "describe-merge".  That
> speaks to:
> 1. saying which revisions to merge
> 2. saying how to get the revisions
>
> But of course, it's too long.

I think that's a pretty good definition of it.  This could *almost*
but not quite be in merge, with::

  merge --by-mail-to bazaar@

but it doesn't do the merge at the time the command is done, and so I
think this is really a different verb from merge.  We could
call it indirect-merge, but that's not so pithy.  I think this is the
key operation, and these are details:

 - to send mail directly, or produce a file you can send

 - to include all the revision data, just a patch, or just a branch url

On the other hand I do think having 'merge' and 'pull' accept bundles is
fine, because it does end up doing the same thing as from a branch - it
updates your local branch and in the case of merge lets you review and
commit.

> > What do you think of the SVK approach of adding extra options to push
> > instead of introducing new commands?
>
> Since push doesn't normally do merges or commits, I think it's horrid.
> It's basically giving two commands the same name.

Agree.  (I could see sometimes having pull do a merge into the
workingtree, but the asynchronous aspect seems to make this very
different.)

> > Is that something we ever
> > considered? (I'm not saying we should do that. Just checking we
> > explicitly rejected it.)
>
> I haven't really enumerated my approach before, but here are the things
> I consider:
>
> 1. From a high level, is it really a variant of the existing behavior?
>    (log --short is a good example of an option that produces variant
>     behavior)
>
> 2. Does association with the existing command enhance discoverability?
>    (This is less important now that we include see-also)
>
> 3. Would it require substantial changes to the existing command's
>    syntax?
>    (pull --merge would require adding many options to pull that would
>     only have an effect if --merge was specified.)
>
> 4. Are users likely to want to make this the default behavior?  (If this
> behavior is a replacement for the default behavior, an option makes
> sense to me.)
>
> 5. Is it likely to be used frequently? (frequently-selected behaviors
> make more sense as separate commands to me)
>
> So to me, push --directive fails because of 1, 2, 3, 4 and 5.
>
> Something like merge --record might make sense for reasons 1 and 2.  On
> the other hand, 3, 4 and 5 weigh against merge --record.

In the way I work now, with a branch per feature that are pushed to a web
server and also sent to the list, I can imagine that when I finish a
feature I'd want to do

  bzr push    # to sourcefrog.net/bzr
  bzr send    # to the list for review

I do see them as different operations.

Maybe we should keep bundle as a lower-level or hidden command, but use
send as the main interface.

-- 
Martin