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

[Ian Clatworthy]

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?

>> If we're introducing "submit" and making "bundle" an alias of it, the
>> partial argument about not changing bundle's UI disappears doesn't it?
> 
> Not really, no.  In certain common uses, "submit" behaves the same as
> "bundle".  The similarity is close enough that I think it's helpful as
> an alias.
> 
> 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. :-)

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.

What do you think of the SVK approach of adding extra options to push
instead of introducing new commands? Is that something we ever
considered? (I'm not saying we should do that. Just checking we
explicitly rejected it.)

Ian C.