Better name for dpush wanted

[Stephen J. Turnbull]

I wrote an even longer reply, which I will probably rephrase into a
blog post.  Since I don't have blog yet, this may take a bit ... if
there's interest I could post as is.  But let me restrict this post to
possible immediate improvements.

Brian de Alwis writes:
 > 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  

Here I must apologize.  "Cheap shot" came to mind first, but I really
meant "low hanging fruit".

 > appreciate your efforts in trying to improve bzr, but I disagree with  
 > some of your proposals which, IMHO, stem from your experience with git.

Some of them do, and of those, some should be laughed out of court.
You know what?  I think this mailing list needs an equivalent to
"unpythonic".  In Python, people who know the customs recognize that
as meaning "there are other ways of doing it that are good but this is
our way, we have good/coherent reasons for it, and it won't change",
and drop the thread.

 > 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 improving docs would].

What it buys is that you get to choose whether a branch refers to a
shared repo or a branch-local one when you make it, rather than
earlier (possibly much earlier) in the planning phase.  Really, the
user doesn't want to know anything more about the repo than which one
is being used.  The rest can be handled behind the scenes by the VCS,
including the initialization, IMO.

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

It's unlikely that Mark Shuttleworth would take it seriously enough to
say "we *need* to work on the UI" if that was all there was to it.

 > 1. Differences in how bzr and git+hg maintain on-disk representations  
 > of content, particularly anything to do with repos.

[Aside: From the point of view of improving Bazaar, we should keep git
and hg separate.  I see Mercurial workflows as being a very close
substitute for the subset of Bazaar workflows that are based on
branches (not checkouts and not looms).  Am I missing something?]

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

I don't understand the difference between "a repo with a single
branch" and "explicit on-disk branches".  AFAICT if you disabled the
hg-branch command, and just used hg-clone, you'd end up with the same
workflows.  Do just you mean you like branches whose names are
identical to the names of their storage?

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

Sure.  Again, one of Bazaar's selling points is its flexibility.  But
... the DAG model of Mercurial and git can represent Bazaar-style
branches, but that's not true in reverse at the UI level (ignoring
looms, an in-progress plug-in).  So saying "we don't do DAGs"
undermines the flexibility claims.

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

That's fine and good at that level, but it doesn't address the issue
that finely differentiated commands create a complexifying pressure on
the internals, which in turn is reflected in hard-to-document
restrictions on the UI.  There is a whole family of those associated
with formats apparently developed to support one command, at the very
least.  There are more such in the pipe.  When does it stop?

And the "every variant a command" leads to abuses like the gtk
plugin.  AFAICS most of those commands should be invisible.  They
should wrap the corresponding command, checking for a GTK+ display,
and automatically using it (unless disabled by a config or option).
Even where they have semantic differences.

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

There's a saying of Pythonistas: not every three-line function needs
to be a built-in.  To borrow your analogy, I think that a lot of the
commands are specialized enough to belong in ~/bin, not /usr/bin.  Eg,
for "bzr ignored", why not do "bzr alias ignored='ls -v --ignored'"?
The documentation for ls doesn't say what -v does; it may not
currently provide the pattern, but that seems like a pretty reasonable
UI to me.

Note that this should allow you to use the various general ls options
like --from-root even if you do create the alias as above, whereas at
present they're unavailable (at least, undocumented) if you use bzr
ignored.

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

Well, if you have a use case for "missing" outside of "what do I need
to push/pull?", I agree with your intuition.  I don't have such a use
case, so my intuition says "Is missing the right command?  Darn, which
way does that go?  Is it a symmetric difference?" and I have to look
it up (and the document doesn't actually say, you have to deduce it
from the presence of the --mine-only and --theirs-only options).
Mercurial's nomenclature makes the mapping obvious: incoming = pull
--dry-run, outgoing = push --dry-run.  Again, your explanation above
maps "missing" to "incoming", but my own use-case is overwhelmingly
biased to "outgoing"!  Also, to me "missing" could refer to files, not
revisions (that's why I classed it with ls, as Wouter recognized).

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

The object of "pull" according to English is a set of commits, which
are to be moved from the source branch to the target, and integrated.
English does not imply any pre- or postconditions on the target.  When
you pull your son from your home to the playground in a little red
wagon, does the playground become your home when you get there?
Weren't you pulling him precisely because the playground has content
not present in your home?

It certainly doesn't help that all other DVCSs I've used make pull
into a variant of merge with different syntax (except git, which can't
merge remote branches directly).  As somebody pointed out, "mirror"
would be more apt here, and would not confuse people used to pull's
semantics on all other DVCSs, as an added benefit.

I think in both cases ("missing" and "pull") your intuition is simply
conditioned by your preferred DVCS so that you don't recognize that
they can easily be confusing to others.