Help: approach for rebasing to older commits after merging more recent commits

[Jay Soffian <jaysoffian@gmail.com>]

[He asks again...]

I have an interesting problem I'm not sure how best to tackle.

A small development team is basing its product on an upstream git repo that is
itself an svn clone. Currently the process looks like this:

r1--r2--r3--r4--r5   upstream trunk   (git svn clone)
 \       \       \
 A---B---C---D---E  local trunk      (git clone of upstream)
      \     /
       F---G        developerN trunk (git clones of local)

So local trunk has both daily merges from the local developers, as well as
less periodic (typically weekly) merges from upstream trunk. The reason being
that it is necessary to remain on top of the upstream bleeding edge.

This works out okay, but there is a minor problem and a major problem.

The minor problem is that the local trunk is cluttered with the developerN
merges. That is easy to solve by having local developers rebase before pushing
to local trunk. That would look like:

r1--r2--r3--r4--r5            upstream trunk
 \       \       \
 A---B---C---D---E---F'---G'  local trunk

The major problem is that local trunk is also cluttered with merges from
upstream. The is a problem because at some point in the future, upstream
is going to declare some rN as being officially blessed. And we're going to
want to rewind any rN changes past that point.

So the question is, what's the best way to do this? Say r2 is blessed by
upstream. The obvious thing to do (I think...) is:

(local-trunk)$ git rebase -i r2

removing C and E from the pick list.

But, occassionally the merges from upstream require much conflict resolution.
Would enabling rerere during merges help with the rebasing? I would want to
reuse as much conflict resolution as possible.

Is there a better approach altogether? Should we be doing something other
than merging to stay atop upstream?

Suggestions/comments greatly appreciated.

j.