git - How to inject a version between some two arbitrary versions in the past?

Question

Suppose I have the following version history on my local-only branch:

A -- B -- C

How do I insert a new version X between A and B, so that the version history looks like this:

A -- X -- B -- C

Note, there is a similar questions on how to insert a commit in the past however, in my case it's a bit different: any changes introduced by X won't propagate to B, which should stay the same after version X is inserted between A and B.

Answer 1

If you want to add the commit, but make it have no effect on the source, then yes, you do need a different path than an interactive rebase.

There is nothing specifically designed for this, but it's relatively easy to do with git replace:

1. Check out commit A (as a detached HEAD, or on a new branch, but the new branch will soon be useless): git checkout <hash-of-A>.
2. Make commit X (however you want it to appear).
3. Run git replace --graft <hash-of-B> HEAD.

You now have this actual history:

  X--B'    <-- refs/replace/<hash-of-B>
 /
A--B--C   <-- whatever-branch-this-is

What's special about these "replace" objects is that whenever Git is about to do almost anything with almost any object—including "use a commit for whatever purpose", for instance—Git will look to see if there is a refs/replace/ name with the object's hash ID. Since there is a replacement for B, Git will now look instead to B'. Hence, git log and other Git commands will act as though the history is:

A--X--B'--C

Note, however, that the real history is still present in this repository. The substitute history is used if and only if the refs/replace/ name is in the repository—which of course it is, in this repository—and replacement is enabled (which it is by default). But if you clone or push this repository elsewhere, the fetch or push process normally does not transfer any refs/replace/ names; so a clone of this repository will switch back to the old history. (You can also view the original history by disabling replacements, using git --no-replace-objects log ... for instance.)

If you like, you can now run git filter-branch, which simply copies commits. By default, git filter-branch obeys the replacement rules. This means that when it copies the commits on the branch, it will start with A, then copy X, then copy B', and then copy C pointing to B'. The copies of A, X, and B' will be bit-for-bit identical to the originals, so will actually re-use the originals; but the copy of C will be slightly different: it will use B' as its real parent, not as a substitute, grafted parent. So commit C will be copied to new commit C' and the branch name, whatever it is, will be made to point to the new copy.

This filtered branch has actual (not just grafted) history that traverses back through B' to X to A, so now if you clone the filtered repository, the history seen in the clone will likewise start from C' and work its way back through B' to X to A.