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

I am not being disingenuous.  My position is that "only a few
combinations are useful, and we can break those out as
separate commands".  You are arguing against that, so I believe you are
arguing against commands like branch and init.

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

Branch creates all of those.

> I am not arguing against an additional command for the common case;

I guess our disagreement is that I think we should support all useful
operations, not just the most common ones, with additional commands.

> it can even
> be defined as an alias for "bzr create" with appropriate options.

Defining it as an alias means that it doesn't have its own help, which
is a loss IMHO.

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

My point is that short options are precious.  This is why my "bzr patch"
plugin doesn't support '-p', just '--strip'.

> I think you still need to detect an existing .bzr dir and whether the command
> invoked by the user is valid in this context.

It is true that bzr create and bzr checkout would both need to avoid
performing bad operations on existing directories.  But bzr create would
also need to ensure that the options passed to it made sense.

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

No, I'm arguing against what I believe your position to be, and I don't
like that accusation very much.

I am saying "branch", "create-repository", and "checkout" are better
commands than "create", because they mean that users who are only trying
to create a repository do not have to read through information on
creating checkouts.  All of the help on "create-repository" will be
information that helps them do what they're trying to do right now.  I
think that's a win.

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

This is because rsync performs two strongly-related operations: copy a
file, and mirror a directory.  A better comparison with bzr create would
be the tar man page.

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

We already know that people don't read the last line of the bzr command
help: "bzr help commands  list all commands".  That line is meant to do
almost exactly what you're proposing: inform people how to get more
verbose output.  Yet we keep getting people who think the listed
commands are all that exist.

> 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

I'm not sure this is much better than tla's -H.  I'd tend to agree that
if we did it at all, --verbose would be better.

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

iD8DBQFD61PB0F+nu1YWqI0RAnKeAJ9RxR22JReXp1GsRE0rNes76chXEACfVi/p
eUHg3QLctijkntkwrXmsKNc=
=/nvF
-----END PGP SIGNATURE-----