Better name for dpush wanted

[Joseph Wakeling]

Russel Winder wrote:
> On Fri, 2009-04-17 at 21:09 +0200, Joseph Wakeling wrote:
> 
>> Something like 'push --shove' is very funny and apt after you know what
>> it's for, but not useful before it, because as a command name it doesn't
>> give a good idea as to what it's actually for.  By contrast something
>> like push-foreign or push --foreign gives you a pretty good idea what it
>> does even before you read the 'How do I push to another VCS?' documentation.
> 
> I think this discussion (aka argument) is going to become a bit
> interminable unless there is a move to create some form of agreement.
> For good or ill the current name is "dpush" as a separate command name.
> Given the (weak) analogy of "git commit" and "git svn dcommit" to "bzr
> push" and "bzr dpush", the status quo actually works fine for me.

I'd actually agree with that, provided forms like 'dCOMMAND' are
standard among other vcs (see my earlier email on the subject:-)

> So Issue 1 is
> 
> 	Separate command or option?
> 
> I argue that because "dpush" changes the source branch from which the
> pushing occurs  a separate command is essential.  "push" never changes
> the source branch, it always only changes the push branch.  This seems
> like a nice safe haven for users, they can guarantee that no matter what
> disaster happens during the push, the source branch is safe.  If "dpush"
> becomes an option to "push" then this invariant is not available.

I'd also favour a separate command.  Secondary to your argument is the
fact that a separate command will be highlighted in 'bzr help commands'
so a new user may get a hint that this command exists even before they
start reading documentation on working with other systems.

If you only have an option like --foreign, then you have to start
reading documentation (at a minimum, the help page for push) before it
is even hinted at that a different type of push exists or is necessary
in some circumstances.

> Issue 2 is of course dependent on Issue 1 but can be made at the same
> time by judicious choice of labels.
> 
> 	What command name?
> 
> To be honest "dpush" works for me exactly because it is bizarre and yet
> abstract.  Clearly it is some form of push, but it is a separate command
> with a weird d that no-one knows the reason for.  Excellent -- the very
> bizarreness is a great flag that there is an issue here, "dpush" pushes
> but in a weird way.
> 
> If there has to be an alternative, it needs to be descriptive of what it
> is doing.  Most of the suggestions to date have been related to the
> nouns in the system which isn't necessarily helpful since a command
> should be a verb form.  So this leads to things like "push-with-rebase"
> being preferred since it is going to describe what will happen, not what
> it is happening to.  The "to" here are well known the source branch and
> the push branch -- which in this case will actually be a Subversion, Git
> or Mercurial repository.

It seems to me there are two options here for a command like this.  The
first is to attempt to match what is found among other tools (if a
consensus exists), so as to maximise the familiarity for people
switching from other tools.  So, for example, dpush can be kept in
analogy to dcommit in git.

But, _is_ there in practise such a consensus among the other tools?

The second is as you say to pick a command that gives a description of
what it's doing.  Here I'd say the command name should follow what the
command is _for_ and this is where I'd favour push-foreign, because that
gives you a strong hint about the function of the command -- pushing to
a foreign branch -- as opposed to something like push-with-rebase, which
tells you literally what the command is doing but is meaningless unless
you know what a rebase is, and offers no clue as to when you might want
to use it.

This is just going by my own use of bzr, where if I want to do something
unfamiliar my typical habit is to start with 'bzr help commands' and see
if there's something that looks like it might be what I need.

> Clearly there is the issue of whether the activity (be it a separate
> command or an option to "push") is allowed where the push branch is a
> Bazaar branch.  Personally I would say no.  I think this is why the
> "push-foreign" / "push --foreign" is gaining some support, it just
> doesn't describe what is going to happen, it tags that the push branch
> must not be a Bazaar branch.  So if this is true it is relevant, but a
> misnomer if the command is allowed to a Bazaar branch.  If it is
> relevant then perhaps "push-to-foreign" / "push --to-foreign"?

Again, I'd agree with this analysis, which is why I'd favour a
'push-foreign' command which can only be applied to non-bzr branches,
and perhaps a separate --with-rebase option for the regular push command.

I don't have good experience of rebasing and when it might be useful --
I've performed one rebase in my life, a few days ago, working with a
friend's svn trunk, and got burned :-(  So don't know really under what
circumstances one might want to push to a bzr branch with a rebase.  But
it seems to me that pushing to a foreign branch is something that should
be highlighted as different from a push with rebase: the rebase may be a
necessary condition of the former, but it's not the actual _focus_ of
what you're trying to achieve.

   -- Joe