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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

>> 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".

> 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.

> 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.

> 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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGn4+c0F+nu1YWqI0RAhoZAJ4jDWIfsMSzczeWPHeXfNZdtUExgQCfYdXb
b3WsBfCWIq6iXfoAw5YJT0Y=
=m7Z3
-----END PGP SIGNATURE-----