CODEWITHSUNDEEP
git
Pavel P
Pavel P

Reputation: 16877

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

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.

Upvotes: 6

Views: 1346

Answers (2)

Tim Adye
Tim Adye

Reputation: 111

Expanding on @torek's excellent answer, here is what I did to insert an old version of file F (saved in F.verX) between commits A and B on branch C:

git checkout A
cp -pf F.verX F
git add F
olddate=$(LC_ALL=C date -r F)
LC_ALL=C GIT_AUTHOR_DATE="$olddate" GIT_COMMITTER_DATE="$olddate" \
  git commit -m "[old version inserted $(date +%F)] commit message for version X"
git replace --graft B HEAD
git filter-branch HEAD..C
git checkout C
git push -f

This sets the author and commit dates on the old commit based on the file modification date. Without this, the commit will have today's date, and will show up at the top of the log if sorted by date (eg. with github history). olddate is set to the date in the correct format for git. Of course you can set this to any other date with, eg. date -d "23 Jan" instead of date -r F.

I added a comment to the commit message with the current date, but that's not needed of course.

git filter-branch makes new commit hashes for everything on the branch after the inserted commit. That's why you need git push -f. Warning: this will mess up anyone else's changes on that branch. The actual commits will be the same as before.

Upvotes: 0

torek
torek

Reputation: 489203

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.

Upvotes: 7

Related Questions