Setting git parent pointer to a different parent

Question

Using git rebase. It's the generic "take commit(s) and plop it/them on a different parent (base)" command in Git.

Some things to know, however:

1. Since commit SHAs involve their parents, when you change the parent of a given commit, its SHA will change - as will the SHAs of all commits which come after it (more recent than it) in the line of development.

2. If you're working with other people, and you've already pushed the commit in question public to where they've pulled it, modifying the commit is probably a Bad Idea™. This is due to #1, and thus the resulting confusion the other users' repositories will encounter when trying to figure out what happened due to your SHAs no longer matching theirs for the "same" commits. (See the "RECOVERING FROM UPSTREAM REBASE" section of the linked man page for details.)

That said, if you're currently on a branch with some commits that you want to move to a new parent, it'd look something like this:

git rebase --onto <new-parent> <old-parent>

That will move everything after <old-parent> in the current branch to sit on top of <new-parent> instead.

If it turns out that you need to avoid rebasing the subsequent commits (e.g. because a history rewrite would be untenable), then you can use the git replace (available in Git 1.6.5 and later).

# …---o---A---o---o---…
#
# …---o---B---b---b---…
#
# We want to transplant B to be "on top of" A.
# The tree of descendants from B (and A) can be arbitrarily complex.

replace_first_parent() {
    old_parent=$(git rev-parse --verify "${1}^1") || return 1
    new_parent=$(git rev-parse --verify "${2}^0") || return 2
    new_commit=$(
      git cat-file commit "$1" |
      sed -e '1,/^$/s/^parent '"$old_parent"'$/parent '"$new_parent"'/' |
      git hash-object -t commit -w --stdin
    ) || return 3
    git replace "$1" "$new_commit"
}
replace_first_parent B A

# …---o---A---o---o---…
#          \
#           C---b---b---…
#
# C is the replacement for B.

With the above replacement established, any requests for the object B will actually return the object C. The contents of C are exactly the same as the contents of B except for the first parent (same parents (except for the first), same tree, same commit message).

Replacements are active by default, but can be turned of by using the --no-replace-objects option to git (before the command name) or by setting the GIT_NO_REPLACE_OBJECTS environment variable. Replacements can be shared by pushing refs/replace/* (in addition to the normal refs/heads/*) .

If you do not like the commit-munging (done with sed above), then you could create your replacement commit using higher level commands:

git checkout B~0
git reset --soft A
git commit -C B
git replace B HEAD
git checkout -

The big difference is that this sequence does not propagate the additional parents if B is a merge commit.

^{Note that changing a commit in Git requires that all commits that follow it alse have to be changed. This is discouraged if you have published this part of history, and somebody might have build their work on history that it was before change.}

Alternate solution to git rebase mentioned in Amber's response is to use grafts mechanism (see definition of Git grafts in Git Glossary and documentation of .git/info/grafts file in Git Repository Layout documentation) to change parent of a commit, check that it did correct thing with some history viewer (gitk, git log --graph, etc.) and then use git filter-branch (as described in "Examples" section of its manpage) to make it permanent (and then remove graft, and optionally remove the original refs backed up by git filter-branch, or reclone repository):

echo "$commit-id $graft-id" >> .git/info/grafts
git filter-branch $graft-id..HEAD

NOTE !!! This solution is different from rebase solution in that git rebase would rebase / transplant changes, while grafts-based solution would simply reparent commits as is, not taking into account differences between old parent and new parent!

To clarify the above answers and shamelessly plug my own script:

It depends on whether you want to "rebase" or "reparent". A rebase, as suggested by Amber, moves around diffs. A reparent, as suggested by Jakub and Chris, moves around snapshots of the whole tree. If you want to reparent, I suggest using git reparent rather than doing the work manually.

Comparison

Suppose you have the picture on the left and you want it to look like the picture on the right:

                   C'
                  /
A---B---C        A---B---C

Both rebasing and reparenting will produce the same picture, but the definition of C' differs. With git rebase --onto A B, C' will not contain any changes introduced by B. With git reparent -p A, C' will be identical to C (except that B will not be in the history).

Definitely @Jakub's answer helped me some hours ago when I was trying the exact same thing as the OP.
However, git replace --graft is now the easier solution regarding grafts. Also, a major problem with that solution was that filter-branch made me loose every branch that wasn't merged into the HEAD's branch. Then, git filter-repo did the job perfectly and flawlessly.

$ git replace --graft <commit> <new parent commit>
$ git filter-repo --force

I've made a question like this some time ago, so the complete answer can be found here.

---

Fore more info: checkout the section "Re-grafting history" in the docs