08:16 < abentley> Better phrasing: 'what circumstances should cause us to produce a working tree in a repository branch'?

[Denys Duchier]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> Denys Duchier wrote:
> | I don't believe that
> |
> | 	bzr create --repository --clone ../FOO
> |
> | is so much harder to type than:
> |
> | 	bzr repository
> |         bzr clone ../FOO
>
> You're comparing to the wrong thing.  Compare "bzr create --repository
> --clone ../FOO --checkout" to "bzr branch".

You are being deliberately disingenuous.  The question was about the ability to
create the 3 man kinds of things that bzr offers: repository, branch, and
checkout.  "bzr branch" does not support that.

I am not arguing against an additional command for the common case; it can even
be defined as an alias for "bzr create" with appropriate options.

>
> | or whatever the commands might be; especially if we make short options
> | available:
> |
> | 	bzr create -rc ../FOO
>
> We also want to maintain consistent short names.  '-r' is already taken
> for '--revision'.  We do not have a lot of short options to spare.

So imagine I wrote -RC instead; the point was short options, not specifically
which ones.

> | as for the non-sensical combinations, you'd still have to detect them
> | regardless.
>
> Not if there's no easy way to produce them.

I think you still need to detect an existing .bzr dir and whether the command
invoked by the user is valid in this context.  Just having different commands
doesn't give you that for free.

> | People like
> | terse help when they only wish to be reminded of something they
> already know,
> | and more extensive help (especially including examples) when they
> either don't
> | know or can't remember.
>
> No one likes irrelevant help, and by dividing by formal operation rather
> than use case, you force nearly everyone to deal with things that are
> irrelevant to what they're trying to do.

You are putting up a strawman argument.  Someone mentioned the rsync man page:
there is terse help at the top (the synopsis) and copious help below that deals
with specific use cases; and it would be nuts to claim that rsync would be
easier to use if there were different commands to deal with the different use
cases.

> |  Ok, I am not "people", but I know that's the case for
> | me.  So I'd probably like "bzr create -h" to print the terse help and "bzr
> | create -h -l" to print the more extensive help.
>
> I don't think that's very good.  Many people using Arch didn't realize
> that it had two different help options, and assumed the short help was
> all that was available.

Then print at the bottom of the terse help screen:

	for more help: bzr create --help --long

Actually, I am now thinking that there is a fairly usual convention that
repeating the verbose option gives you more verbosity.  It might be nice to
adopt a similar convention for help: bzr create -hh

Cheers,

--Denys