Workflow question: importing upstream builds

[David Frey]

Let's say I import a build of some software project as a Mercurial
repository.

[imported build n]

I then make two independent changes.  One takes a couple of steps, the
other is
simple and only takes one commit.  My repo now looks like this:

                   [my change 1p1]---[my change 1p2]
                  /
[imported build n]
                  \
                   [my change 2]


I then import a new build from upstream.  Lets say that upstream accepted
the
changes I made in "my change 1p1" and "my change 1p2", but not "my
change 2".

                   [my change 1p1]---[my change 1p2]
                  /
[imported build n]----[imported build n+1]
                  \
                   [my change 2]


I was thinking that I could use rebase to move "my change 2" to build
"n+1" so
the repo would look like this:

                   [my change 1p1]---[my change 1p2]
                  /
[imported build n]----[imported build n+1]
                                          \
                                           [my change 2]

The problem I have is that it's unclear what needed to be rebased and
what was
accepted upstream.  Does it make sense to do some sort of dummy merge
where I
do:
hg update -C -r {imported build n+1}
hg merge -r {my change 1p2}
hg revert --all -r {imported build n+1}
hg commit -m "dummy merge to eliminate head of changes accepted
upstream"

If I had done this before and then performed the rebase, I would end up
with a
repo looking like this:

                   [my change 1p1]---[my change 1p2]
                  /                                 \
[imported build n]----[imported build n+1]-----------[dummy merge]
                                                                  \
                                                                   [my
change 2]

Is what I have described a normal practice or am I abusing Mercurial?

Thanks,
David