How to add additional parents to old git commits?

Question

I have a project containing two branches: master and gh-pages. They are essentially two different projects, where the gh-pages project depends on the master project (and not vice versa). Think of it as "master contains the source code, gh-pages contains the binary built from those source files". Periodically, I take the changes that have accumulated in master and make a new commit to the gh-pages branch with the commit message "Bring into line with master commit xxxxxxxx."

After a while of doing this, I realized that it would be nice if the gh-pages commit "Bring into line with master commit xxxxxxxx" actually had xxxxxxxx as its parent in the git repository. Like this (bad MSPaint art):

Is there a way to make the repository look like the second image above? I know how to make new commits follow this pattern: I can do "git merge -s ours master" (which sets the parents of an otherwise empty commit) followed by "git commit --amend adv550.z8" (where adv550.z8 is the binary file that's actually changing). But does git make it easy to go back in time and add new parents to old commits?

I am perfectly willing to "git push -f" and blow away the current history of my Github repository, once I get my local repo looking right. The question is, can I get my local repo looking right?

---

EDITED YEARS LATER TO ADD: I eventually abandoned my attempts to make the git history of gh-pages look like that; I decided that it was too much work for zero gain. My new practice is to aggressively squash commits to gh-pages, because saving those commit messages really doesn't matter in my case. (It's just a long line of "Bring into line with master commit..."s, none of which are historically interesting.) However, if I needed to do this again, I'd listen to the answers that said

git merge $intended_parent_1 $intended_parent_2
git checkout $original_commit -- .
git commit --amend -a -C $original_commit

Answer 1

You can't go back in time and change existing commits. Even when you do something like git commit --amend, you're not actually changing the commit; you're creating a new one at the same place in the tree with all the content from the original (plus your changes). You'll notice that the commit hash changes after the --amend, and the original is still present in your repo--you can get back to it with git reflog.

On the other hand, you can go back in time and create an alternate universe. Essentially, you would go back to your gh-pages branch point and recreate the whole thing (with e.g. git cherry-pick or something) as a parallel branch. The hashes would change, because the commits are different objects.

(I'm curious why you have your repo set up as separate branches, instead of separate directories in the same branch. It seems like the code -> build process would get tedious.)

Answer 2

git replace --graft $commit $parent1 $optional_parent2

git replace --graft $original_commit \
    $(git show --pretty=%P $original_commit) \
    $additional_parent

Explanation: git replace --graft allows to respecify which are the parents of a given commit. This works by writing a new commit with the respective alterations and writing a replace ref that causes git to look up the new commit instead of the original one whenever it is accessed.

git show --pretty=%P $original_commit just lists the original parents.

Answer 3

@rumpel gave the right answer. Allow me to share the snippets that I use.

First, I've created orphan master branch:

git checkout --orphan master
git commit --allow-empty -m 'Init'

My use case is slightly different, the site I want is in _site directory on develop branch. Therefore I do:

git checkout master
git rm -rf .
git read-tree develop^{tree}:_site
git checkout -- .
git commit -m "Update from develop SHA1:$(git rev-parse --short develop) ($(git log -1 --format=%cd develop))"
git replace --graft @ $(git show --pretty=%P @ | head -n1) develop

Note that in last command, I had to filter by | head -n1 since my git output a lot more than just parents.

Answer 4

These are your magic words:

git merge origin/master --strategy ours

Execute this in the gh-pages branch in order to record the relation to master without actually changing anything. This worked for me when I created the gh-pages branch as --orphan, as in this answer.

You can even --amend this empty merge commit afterwards in order to introduce the changes you actually want to make to your "pages". See https://github.com/krlmlr/pdlyr/network for an actual example on GitHub.

Answer 5

You can rewrite the commits, but it requires rewriting the entire branch starting from the first commit that needs an additional parent up to the branch tip. Is is (like with rebases) a new branch that just has the same contents.

The trick is to use commit-tree, which takes everything (committer/author info, timestamps, commit message, list of parents), albeit in a rather unpractical way. A bit of scripting does the job then.