The push|pull vs update distinction

[Jelmer Vernooij]

On Tue, Jan 15, 2008 at 04:19:20PM +1000, Ian Clatworthy wrote:
> 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.
+1. It would be awesome if bzr could do that. I've seen quite a few
people bitten by that. 

Related to this, it would still be nice to
split the "bzr update" command - having a separate command for
updating an out of date working tree. That way, "bzr up" could error
out if it is being run on an unbound branch and suggest people to run
"bzr pull" rather than confuse people by saying it's up to date.

> The lack of implicit commit after merge is actually a feature IMHO.
The lack of it is also a missing feature. Perhaps we could just
provide a plugin that does git-style pull so we can tell people who
ask for it "it's not recommended, but if you're really sure, use this
plugin" but don't need to have it in core.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080115/94736219/attachment.pgp