merge vs pull (was What we did at UBZ)

[Erik Bågfors]

> > Right now, bzr help is 13 commands. That's pretty good, and a very, very
> > powerful selling point. I think that its reasonably possible to get that
> > down to ten commands without breaking new minds, by combining three
> > commands -- pull, branch and merge, into one command.
>
> Well, combining three into one would only get it to 11 commands. :-)
>
> More importantly, having few commands is not a win if the behaviour of
> those commands is unpredictable.  It's not an end in itself.  It seems
> that a combined pull/merge would be somewhat unpredictable both in
> whether you later need to commit, and in whether it forms a rolled-up
> commit or not.

I just want to agree here.  Less commands are not the most important
thing as long as they are clearly defined.  I find the current
pull/merge to be good enough.  I rather NOT have pull do some magical
thing where you sometimes have to follow up with commit and sometimes
not.  That's the only reason I prefer to keep them as two different
commands.

I find mercurial to be very confusing in that regard.  Since it works
differently there is no merge command, which is fine.  But you pull
into your "archive/repository" and then run "hg update" to update the
working three.  It then complains that you have to use "hg update -m"
to merge. That's ok also. But what you don't know then, is that you
have to commit if you run with -m and not if you run without.

I think it's better to have them as different commands.

Regards,
Erik