merge vs pull

[Jamie Wilkinson]

This one time, at band camp, Michael Ellerman wrote:
>bzr. In terms of merge/pull there's ~three classes of users:
>
> * Serious developers who branch, hack, merge, hack, remerge, branch, pull,
>   push, tag, etc.
> * Budding/lazy developers, who track mainline and every now and then do some
>   hacking.
> * Keen users who just want to track mainline.
>
>Different projects will have different percentages of each, but as I see it 
>for a lot of projects the latter category is going to be large.
>
>My point is these users don't need to know about merge, they just want to grab 
>the latest development code, try it out, and update it every now and then. If 
>they need to merge then something's gone wrong.

.. if they hack on their own branch, and commit, then something's gone
wrong? :)

>In fact I think it would be cool to have a 'mirror' command, for exactly these 
>kind of users. The first time you run mirror it would do a branch, on 
>subsequent runs it would do a pull. So your doco for "how to track mainline" 
>would be:
>
>$ bzr mirror http://some.url.com/repo/path
>
>Having such a command would I think make it _more_ feasible to combine merge 
>and pull. That is, mirror would cater to most users, and to the simple use 
>case. pull/merge could be reserved for more advanced users, and as such do 
>more useful but perhaps slightly confusing logic.

Call me daft, but I don't see how that differs from 'pull' right now...

I reckon I fit somewhere between the second and third categories above,
working out the difference between merge and pull isn't hard.