updating checkouts with no upstream changes

[Russ Brown]

I just ran into some behaviour with checkouts which came as a surprise 
(I was expecting it to be different). Just wondering if this seems right 
to everyone else, and if not if I should raise a bug to get it changed. 
I discussed it with James Westby on IRC and he thought it was worthy of 
discussion.

The situation is this. Say I checkout branch 'upstream' with revisions 
A-B-C. My checkout is called 'downstream'.

In my checkout I make a change and commit using --local.

At this point the two branches look like this

upstream    A-B-C
downstream  A-B-C-D

The issue is what happens when I run bzr update on 'downstream'. The 
behaviour I'd expect is for nothing to happen, since nothing upstream 
has changed. However, it pulls out my commit and converts it into a 
pending merge, and updates all files back to state C. If I want to carry 
on working locally I have to do commit with --local again, and this 
produces a new merge commit with my original commit as one of its parents.

My expectation is that if I'm updating, and the upstream branch doesn't 
have any new revisions that I don't have already, it shouldn't do 
anything. That might be oversimplifying the rules that I'm actually 
expecting, but I'm not an expert on the logic involved here...

What does everyone else think?

-- 

Russ.