When git rebasing two branches with some shared history, is there an easy way to have the common history remain common?

Question

Suppose we have the following revision graph:

A-X-Z--B
     \\
      \\-C

with A preceding both B and C. Further suppose I rebase A from up

Answer 1

The problem in the general case

I was concerned with a similar problem: rebasing a whole subhistory -- several branches, with some links between them resulting from merge:

A--B-B2-B3 <--topicB
\   /
 \-C-C2-C3 <--topicC

If I run several git rebase sequentially (for topicB and topicC), then I doubt the merges between the branches can be preserved correctly. So I would need to rebase all the branches at once, hoping that would reconstruct the merges between them correctly.

A "solution" that worked in a specific subcase

In my case, I had luck that topicC was actually merged into topicB:

A-B-----------B2-B3 <--topicB
   \         /
    \-C-C2-C3 <--topicC

so to rebase the whole subhistory, I could just run

git rebase -p A topicB --onto A*

(where A* is the new base, instead of A, as in your question; topicB is the branch name that would initially point to the old commit B3 and to the rewritten commit B3' afterwards; -p is a short name for --preserve-merges option), obtaining a history like:

A-B-----------B2-B3
   \         /
    \-C-C2-C3 <--topicC

A*-B'-------------B2'-B3' <--topicB
    \            /
     \-C'-C2'-C3'

and then reset all remaining branch refs (and tags) to the new corresponding commits (in the new subhistory), e.g.

git branch -f topicC C3'

It worked:

A*-B'-------------B2'-B3' <--topicB
    \            /
     \-C'-C2'-C3' <--topicC

(Moving the branch refs and tags could perhaps be done with a script.)

A "solution" for the general case inspired by that specific one

If topicC was not merged into topicB, I could create a fake top commit to merge all the branches I want to rebase, e.g.:

git checkout -b fake topicB
git merge -s ours topicC

and then rebase it that way:

git rebase -p A fake --onto A*

and reset the topic branches to the new commits, delete the fake branch.

Other answers

I believe that the other answer with --committer-date-is-author-date is also good and sensible, but in my experience with Git, I hadn't had that idea and solved the problem of keeping the shared history really shared after a rebase the way I have described in my additional answer here.