merge vs pull

[Kevin Smith]

John Arbash Meinel wrote:
> Kevin Smith wrote:
>>
>>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.

Ok. So pull should (maybe already does) tell the user if there were 
conflicts, and describe how the user could find them. Maybe with a 
--verbose or --show-conflicts option that would list all the files that 
had conflicted. Those will now have >>>>> conflict markers, right?

I think I "get it". It would be great to get full descriptions of pull 
and merge up on the wiki, or somewhere online.

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

Yes, I think that's a great feature.

Cheers,

Kevin