Basically, I just want to (re)set the parent (let's say to commit A) of a specific commit (commit B) which is the root commit of some branch x. It is suggested here in one of the answers that I can do that via grafts. I will try that later, maybe it's the better way.
However, before reading this, I thought that this should be possible via rebase. But because the parent commit A differs a bit from B and I just want to stay the whole branch x the way it is, just with setting a parent to its root commit B, I thought I might use the theirs strategy -- which doesn't seem to exist. I have stumbled upon this earlier (and thought it was a bug or in my Git installation) and always just worked-around by switching branches and using the ours strategy. However, with rebase, I am forced to use the theirs strategy in this case.
My command looks like:
git rebase -s theirs --onto A --root x x--rebased
rebase isn't designed for what you want to do. The other poster was correct; what you want to do is set up a graft to attach B to A, then run git filter-branch to bake it into the commits. An example of this exact use case can be found in the git filter-branch manpage.
I'm not entirely sure I understand your question, but if your aim is to go from this:
o C (X)
|
o B
o A
to this:
o C' (X)
|
o B'
|
o A
then git replace --graft B A should do what you want.
N.B. B and B' have the same filetrees as each other, but different commit hashes because their parent commits are different. Likewise C and C'.
Why this has to be done via git replace --graft rather than git rebase -s theirs, I don't know. Presumably it is for hysterical raisins.
Also see: this answer to How do git grafts and replace differ? (Are grafts now deprecated?).
来源：https://stackoverflow.com/questions/6088440/git-how-to-use-rebase-with-theirs-strategy