The push|pull vs update distinction

[Ian Clatworthy]

Andrew Cowie wrote:
> Chatting today in #bzr, we had a user who had not realized the
> implications of `bzr push` not running update across a remote transport.
> 
> The root cause of his problem turned out to be something else, but along
> the way it was pretty clear that he was puzzled by why `bzr push` was
> "just working" locally and "not working" remotely.
> 
> In passing I made a suggestion to Robert that perhaps we face a slight
> education issue here: although it is clearly awesome that Bazaar just
> gets on with it and does the sensible thing when a `bzr push` is done
> locally by implicitly invoking `bzr update`
> 
> He noted that even just a single output line like "now running update"
> or whatever might help people realize that there are two steps being
> done [locally], and asked me to mention it in an email.
> 
> ++
> 
> <discussion>
> 
> Certainly the other VCSs, notably git, make the push vs update
> distinction very explicit, something which I find somewhat an
> unnecessary pain in the ass. So Bazaar's just-do-it behaviour here is
> clearly superior. I would, however, note that this conflicts with two
> other current behaviours: 1. lack of automatic [commit on] merge, and 2.
> lack of update on push to remote repository when the protocol being used
> (ie the ssh in bzr+ssh) clearly allows it.
> 
> Now, I understand the arguments against both of these, but they are both
> cases where the just-do-it vibe is not taking precedence and, taken as a
> whole, just getting on with some things and not others (especially where
> the same command behaves differently in similar circumstances) that
> would seem to be jarring in the classic usability sense.
> 
> I obviously bias towards absolute consistency in user interface over the
> system as a whole rather than individual commands being refined at the
> expense of such overall uniformity. Almost all of my (admittedly short)
> list of concerns with Bazaar fall into this category, so I figured I
> would mention my observation of this discrepancy. 
> 
> </discussion>

At the moment, it's consistent in the sense that, regardless of
protocol, pull always updates the working tree and push never does.
Rather than making update an option for pull (as Hg does) or outputting
a message saying we're doing that, I think we should leave pull alone
and look at improving push. Perhaps push should update iff:

* there is a working tree
* the protocol supports it efficiently

We could output a warning if we don't update after push to reduce
surprise for those expecting otherwise.

The lack of implicit commit after merge is actually a feature IMHO.

Ian C.