why is update/merge required after a pull?

[Thomas Arendsen Hein]

* Brett Cannon <brett at python.org> [20061031 22:16]:
> I am doing a Mercurial/bazaar comparison (which will eventually hit my blog)
> and I had a question about a design decision for Mercurial.  I noticed that
> after I do a pull I must do an update or merge.  But obviously Mercurial
> knows that one of the two needs to be done to get the pulled changes to be
> applied.
> 
> So I would just like to know why that extra step is needed.  I suspect that
> I am going to get an answer that involves changeset management that I am
> just not aware of because of my brain is very svn-centric at the moment.  =)

There are cases where you don't want to update the working directory:
1. You have local changes which you want to look at first.
2. You have local changes which you want to commit first.
3. You haven't checked out tip, so you don't want to be at tip after pull.
4. You just want to look what's new and probably want to update
   (so that using hg incoming wouldn't be the right thing)
5. You just want to see a diff of what's old and what's new:
   hg diff -rtip
and probably more, these are just the reasons that came in a few seconds.

Of course, you often just want to update, but doing an update later
is easy, while un-updating later isn't. Maybe you don't even know at
which revision you were before.

Special casing you-are-at-tip, you don't have local changes and you
don't have local commits (1+2+3 from above) might lessen the
problem, but then your brain has to cope with two sets of Mercurial
behaviour while now it only it has to learn one.

Apart from these practical reasons, Mercurial likes to distinguish
between repository operations and working directory operations where
practical.

Thomas

-- 
Email: thomas at intevation.de
http://intevation.de/~thomas/