merge vs pull

[John Arbash Meinel]

Kevin Smith wrote:
> Erik Bågfors wrote:
> 
>> As another RCS user (and not a RCS developer) I have to agree. I
>> rather have two commands that does two very defined things (no
>> suprices) than one command that does two things. I think pull and
>> merge are two very different operations, used for two different
>> purposes.
> 
> 
> I think I have been persuaded that there should be separate commands.
> Now, the issue to me is how clearly the docs distinguish between the
> two, and what the app displays to the user after each operation has been
> performed.
> 
> Is there a compelling reason it's called "pull" instead of the old CVS
> favorite "update"?
> 
> Martin said of pull: "This can only succeed if the source is a
> descendent of the tip of the target." If you run it when this is not the
> case, the message must tell the user what to do. (Maybe it already does).
> 
> 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).
> 
> 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.

One reason to use pull instead of update is because of a future change
where we will have checkouts and bound branches, which might use the
update term rather than the pull term. (update my checkout to look like
the branch I am connected to, vs pull new changes from upstream).

> 
> After a merge, assuming the working tree has changed and the archive has
> not, the app should remind the user that a review and commit are required.
> 
> Does merge behave differently with and without uncommitted changes? If
> you try to merge with uncommitted changes, it should refuse by default
> (I think it already does?). Is merging from an identical branch an
> error, or a noop? What about merging from a descendent (the case where
> pull would have worked)...that should succeed with a reminder to commit,
> which would mean that someone could always choose merge+commit and never
> have to learn/use pull.

The only one introduced recently is identical branches. The merge code
now checks to see if there are any actual changes to the tree, and if
not, it won't set a new pending-merge (hence a no-op).

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.

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 just realized you might have been speaking more of what the future
behavior should be, but I wanted to try and remind people of where we
are, versus what the question was.

John
=:->

> 
> 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/f33cc66c/attachment.pgp