I've always thought there had to be a way to solve the shared feature branch + rebasing problem! I'll have to try this out!

The only thing is, while it is easy from the downstream side, it's a little more tricky to prepare the new branch.

One thing you can do is actually do the regular rewriting rebase, install the result under the new name, and then throw the rewrite away.

Rebase our-topic.0 to its default upstream, thereby locally rewriting it:

   $ git rebase

(Precondition: no local commits in our-topic.0: it is synchronized with origin/our-topic.0, so they point to the same commit.)

Now, assign the resulting commit to the newly defined variable our-topic.1:

   $ git branch -t our-topic.1

Now, throw away the local modification to our-topic.0. We don't have to appeal to the reflog, because our-topic.0 is following a remote branch which we can reference:

   $ git reset --hard origin/our-topic.0

(Remember the precondition before all this: origin/our-topic.0 and our-topic.0 pointed to the same commit. Now they do again!)

Finally, push our-topic.1 for others to see:

   $ git push origin our-topic.1

Seems like you could simplify this quite a bit by just creating our-topic.1 before rebasing. Given our-topic.0 == origin/our-topic.0, and our are currently at our-topic.0

    $ git checkout -b our-topic.1

    $ git rebase (-i) master

    $ git push origin our-topic.1

No need to modify and reset our-topic.0.

Yes, thank you for explaining this so well. I commented on that elsewhere, but didn't do it nearly as well as you did.