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

[Aaron Bentley]

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

Denys Duchier wrote:
| Aaron Bentley <aaron.bentley at utoronto.ca> writes:
|
|
|>>I don't see why you believe that separate commands are easier than
separate
|>>options.
|>
|>It's harder to type.  The help is harder to read.  It means one command
|>can do radically different things, including pointless things like "bzr
|>create --repository --checkout"
|
|
| 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".

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

| as for the non-sensical combinations, you'd still have to detect them
| regardless.

Not if there's no easy way to produce them.

| Just imagine that under the hood, you are indeed using different commands.

That's the problem.  It shouldn't be harder to create a standalone
branch with bzr than with cp.

| I
| just don't think that multiplying the commands at the UI-level is a
good idea.
| It seems to me that advertising "bzr create" as the command to create
things
| makes it cognitively simpler for the user.

So does it create tags?  does it create revisions?  Directories?  What
other things can be created?

|>>I think it is easier for a user to remember that there is one command to
|>>create things, and that makes it also easier to lookup the copious
- --help that
|>>should be associated with it.
|>
|>People don't like copious help.  They like direct, to-the-point help.
|
|
| I think you are overgeneralizing on your personal typical use case.

Actually, I was using my day-to-day experience of customer support.  But
really, try using the Bash man page, for example.

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

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

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

iD8DBQFD6r1x0F+nu1YWqI0RAg6oAJ4lPNjwQFCNiPY+rty9krbboY4CIQCfZOEk
xgW1SUKS0qNqmWVs4pMXhP4=
=NzDM
-----END PGP SIGNATURE-----