merge vs pull

[Jamie Wilkinson]

This one time, at band camp, Michael Ellerman wrote:
>On Tue, 29 Nov 2005 00:15, Jamie Wilkinson wrote:
>> This one time, at band camp, Michael Ellerman wrote:
>> >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? :)
>
>Grrr, no if they're trying to maintain a mirror of a branch and they end up 
>having to merge it's a bug. You knew that though didn't you :D

Well, if they're only mirroring, then they already know 'pull', and it
already behaves as expected!

The only time you'd need to know about merge
is if you commit to your tree, or try to merge from someone elses tree -- in
the first case, you know you need merge because the docs already say you do,
and in the second case, yu know you need merge because that's what you're
doing :)

Yes, if they are only mirroring, and they somehow need merge, then that's a
bug, because it's not how bzr should behave.   It doesn't mean that pull and
merge need to be combined, though

>> >In fact I think it would be cool to have a 'mirror' command ...
>>
>> Call me daft, but I don't see how that differs from 'pull' right now...
>
>Well I won't call you daft, just 'cause you might take it the wrong way over 
>email ;) But ...
>
>You can't pull into nowhere:
>
>concordia ~$ mkdir bar
>concordia ~$ cd bar
>concordia ~/bar$ ls -la
>total 16K
>drwxr-xr-x    2 michael michael 4.0K 2005-11-29 02:11 .
>drwxr-xr-x  121 michael michael 8.0K 2005-11-29 02:11 ..
>concordia ~/bar$ bzr pull http://michael.ellerman.id.au/files/diffstat
>bzr: ERROR: Not a branch: /

I think that's irrelevant to the current thread :)   Pull could behave as
branch does, in an empty directory, sure.  (I've been bitten by that a
couple of times, forgetting 'branch' and 'get'.)


>> I reckon I fit somewhere between the second and third categories above,
>> working out the difference between merge and pull isn't hard.
>
>Sure, I'm one category on some projects and another on others. That's not 
>really the point, it's making the initial experience people have with bzr 
>really _kick arse_.

bzr already kicks arse :)

But if pull and merge were to become one and start applying heuristics to
guess what I mean, then I'd start to think that bzr kicked less arse,
because I *want* pull and merge to be separate commands.

A pedantic example: an initial experience assumes one has no working tree
branches -- therefore a persion experiencing their initial experience needs
to get one, or create one.  If you are getting one, then you can only
branch, merge doesn't make sense as a first operation; if you're creating a
new branch, then you have nothing to merge from.