merge vs pull

[John Arbash Meinel]

Kevin Smith wrote:
> 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?

Then you have conflicts in you working tree. Think of it more like "cvs
update". Before you can commit, you have to be up to date (in our case
it isn't have-to it is want-to). You want to resolve conflicts before
you commit, and you always want to be up-to-date.
With bound branches and checkouts, we will allow the user to declare
explicitly that they have to be up-to-date. (The commit will fail if out
of date).

> 
>> 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.

Pull does update the local archive, and then figures out what changes
occurred in that update, and merges them into your working tree.
It definitely does not do the latter.

Merge does more of the latter, though it doesn't do the pretend commit.

(Both of them add the revision information into the local archive, but
pull also updates your branch's revision-history, while merge does not.
Merge refuses to run if you have uncommitted changes, so that you don't
mix the merge changes with your local changes.)

John
=:->


> 
>> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051129/5ce4ce2f/attachment.pgp