merge vs pull

[Kevin Smith]

John Arbash Meinel wrote:
> Kevin Smith wrote:
> 
>>Does pull modify both the archive and the working tree (at least by
>>default)? I tried to answer this myself, but I don't have bzr installed
>>here right now, and I couldn't find any online bzr reference docs (!)
> 
> Pull does both. Because it wants to have a checkout of the last revision
> in the working tree. (Plus whatever local uncommitted changes you have).

Good. I always found mercurial confusing, when pull updated the archive 
but not the working tree.

>>If you try to pull with uncommitted changes, the error message should be
>>clear.
> 
> There is no error. Pull has to work in this situation, because if you
> want to have a shared branch, you don't want to create a fork. So you
> need to update before you commit.

That sounds like it would have to do a merge. First, the archive would 
be updated, but then the working tree also needs to be updated to 
include the just-pulled changes. What if those newly pulled changes 
conflict with my changes?

> In all cases merge will work, even if pull would have worked, and it
> will require a new commit. Right now merge is always followed by commit,
> while the original discussion was if pull should sometimes require a
> commit as well.

I guess that would depend on whether a pull pretends to update the 
archive first, and then does a pretend checkout, or updates the working 
tree first, and then does a pretend commit. I have been thinking about 
it as the former, in which case requiring a commit wouldn't make any sense.

> The original complaint was (paraphrasing): "I tell bzr to do foo, and it
> says, 'I can't do that, do bar instead'. Why didn't it just do bar? I
> hate it when a program knows what to do, but won't do it."
> And I can understand the frustration, but to me, the concepts of merging
> versus pulling are sufficiently different, that we are willing to trade
> off the little bit of annoyance versus having consistency, which
> prevents much more annoyance.

I totally agree. A program that can just do the right thing is great, 
but when that's not possible (as seems to be the case here), one that 
suggests your next move is better than one that just leaves you wondering.

Thanks,

Kevin