How do you deal with a public repository that has already been rebased?

Question

This question has likely been asked before but I\'m having a heck of a time searching for it.

Very frequently, experienced git users will say \"do not <

Answer 1

You should do (as in "How do I recover/resynchronise after someone pushes a rebase or a reset to a published branch?"):

git checkout yourBranch
git branch old-upstreamBranch D # BEFORE fetching!

           E--F (origin/upstreamBranch)
          /
A--B--C--D (old-upstreamBranch)
          \
           X--Y--Z (yourBranch)


git fetch


     L--M--N--O (origin/upstreamBranch)
    /
A--B--C--D (old-upstreamBranch)
          \
           X--Y--Z (yourBranch)

At this point, you cannot simply rebase your branch on top of the rewritten upstreamBranch: that would introduced C and D which were explicitly left asside when upstreamBranch was rewritten.

You need to rebase just yourBranch, and not the commits before it.
That is why you put an old-upstreamBranch tag before fetching:

git rebase --onto origin/upstreamBranch old-upstreamBranch yourBranch

                X--Y--Z (yourBranch)
               /
     L--M--N--O (origin/upstreamBranch)
    /
A--B--C--D (old-upstreamBranch)



git branch -D old-upstreamBranch 

                X--Y--Z (yourBranch)
               /
     L--M--N--O (origin/upstreamBranch)
    /
A--B

But: With Git 2.0, all you will need to do is:

fork_point=$(git merge-base --fork-point origin/upstreamBranch yourBranch)
# return D
git rebase --onto origin/upstreamBranch $fork_point yourBranch

No more "making a branch before fetching!

If you realize the issue after git fetch, you can still rebase your branch nicely on top of the rewritten upstream branch.

---

Since commit ad8261d from John Keeping (johnkeeping), git rebase can use that same new --fork-point option.