Better name for dpush wanted

[Brian de Alwis]

First off, addressing out-of-order:

> That kind of thing is always YMMV, so your cheap shots about "people
> who like git" are counterproductive.

My apologies; it was a lame joke but not intended as a cheap shot.  I  
appreciate your efforts in trying to improve bzr, but I disagree with  
some of your proposals which, IMHO, stem from your experience with git.

> Instead you should try to
> address the stronger criticisms, like "who needs init-repo, which is
> really easy to forget vs init --shared-repo" (which option will be
> necessary if we get a repo feature that doesn't force you to use a
> certain project layout, so it's not necessarily a trade of a command
> for an option).  Or about the various specialized ls commands.

I personally don't find most of these criticisms (except for those  
relating to the overwhelming number of formats) to be particularly  
strong or well-founded beyond personal anecdote.  I'm not sure that  
"init --shared-repo" buys anything more than having a bit of  
explanation in the help for "init" and a cross-reference to "init- 
repo" (which it does, but the help text for init is overwhelmed  
listing the number of formats).

My impression from reading these long long threads is that many of the  
complaints of bzr's UI stem from two reasons:

1. Differences in how bzr and git+hg maintain on-disk representations  
of content, particularly anything to do with repos.  I see this a  
trade-off for having on-disk representations of branches vs the git/hg  
repo with a single branch.  I personally *like* having explicit on- 
disk branches.

2. Differences in background knowledge.  People coming from hg or git  
have developed different mental models about how DVCS tools work, and  
their exposure to bzr is coloured by that baggage along with them.

I see the criticisms more as indicating needs to improve the help text  
on individual commands rather than streamlining commands.

>> What really matters to novices is being able to create and evolve a
>> meaningful mental model of how bzr's commands fit together.
>
> The ten commands that you actually use fit together the same way that
> git's or Mercurial's do.  See PEP 374.  How the other 152 commands fit
> in is another question, and while it's a minor hindrance, I think
> command proliferation in bzr *is* a hindrance to understanding bzr
> just as it is for git.

I see the bzr commands like Unix commands -- specialized tools with a  
purpose.  There are a lot of commands as there are a lot of needs.   
And maybe that's why I found git so frustrating -- actions that should  
have been commands were instead specialized arguments to some root  
command.  It's a matter of perspective: I have my own ~/bin with 290- 
odd specialized commands that I've evolved over time.

Windows/DOS has a much smaller number of commands than Unix.  Does the  
fewer number of commands make the DOS command prompt earier to learn?   
Questionable: I don't see Windows users using their command prompts  
more than Unix users.

The better solution, IMHO, is Jelmer's recommendation to categorize  
the commands.

> Nor do I think that Bazaar has particularly well-named commands.  I
> think Mercurial's "incoming" and "outgoing" are much more intuitive
> than "missing", the relations among "pull", "push", "merge",
> "checkout", "revert", and "update" are quite complex, and pull's
> behavior at least is quite unintuitive.

Intuition is entirely dependent on your past experiences.  Bzr was the  
first DVCS I learned, and that likely explains why I like bzr's  
command names (and why I find git baroque to the extreme, and hg a bit  
weird).  Bzr's names mapped to those of CVS and SVN where there was an  
analogue.  Where there wasn't an analogue (like "missing") the name  
seemed very well picked.  Perhaps I'm contrary, but I find "missing"  
to be far more intuitive than "incoming" and "outgoing" -- "what is  
this branch missing compared to X?"

What makes pull's behaviour unintuitive?  Is it because pull's  
behaviour doesn't map to the similarly named pull on the other DVCSs?

To reuse the analogy to the DOS command prompt and Unix shells: my  
wife recently learned to use the DOS DIR command.  Despite  
subsequently learning that ls produces a much more useful format for  
her actual needs, she continues to use DIR as it was the first one she  
learned and she doesn't need to change.

DVCS is complex, and we don't make it easier by having overloaded  
commands with multiple arguments.  Heck, my experiences teaching 3rd  
year undergrads and a slew of HCI grads and faculty has proven to me  
that even simple CVCSs are surprisingly complex.  Good tutorials and  
willingness from people to explain how and why things work are the  
most important.  I was able to bring someone up to speed to using bzr  
for working on a paper with just a few coaching emails with example  
commands.  I've learned far more about using git from messages on this  
list from you, Matthieu, and Teemu's postings than I ever did from the  
various git tutorials.

Brian.

-- 
"Amusement to an observing mind is study." - Benjamin Disraeli