[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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html