5

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
Community
  • 1
  • 1
Albert
  • 65,406
  • 61
  • 242
  • 386
  • Not exactly what you need, but there are ways to simulate a "theirs strategy": http://stackoverflow.com/questions/4911794/git-command-for-making-one-branch-like-another/4912267#4912267 – VonC May 22 '11 at 16:22
  • 1
    @VonC: I think you didn't know what I meant. I know how to simulate it. The problem is, this doesn't work together with `rebase`. – Albert May 22 '11 at 17:43
  • 1
    hence the "not exactly what you need part". This was to let others know about the "theirs" strategy in general. – VonC May 22 '11 at 20:03

2 Answers2

2

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?).

2

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.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
  • 1
    Just curios: If there would be the `theirs` strategy, how would that be in any way different? And if this would not be different, why would it be bad to use `rebase` here? But anyway, this question was not about how to achieve that but how to use the `theirs` strategy with `rebase`. How to achieve that, that was already answered in another separate question [here](http://stackoverflow.com/questions/6088551/git-what-is-a-graftcommit-or-a-graft-id). – Albert May 22 '11 at 22:31
  • @Albert, rebase applies every commit on the branch as a patch. This linearizes history, and brings up the possibility of merge conflicts. If your history has no parent commit, this means you'll have a new file/new file conflict, and I suspect a take-theirs strategy might end up simply emptying out the first commit in the sequence entirely... – bdonlan May 23 '11 at 01:08
  • 1
    The sides are swapped at rebasing, i.e. the theirs strategy is actually the ours strategy. I.e. the first commit will exactly stay as it is. As well for all the other commits. – Albert May 23 '11 at 17:25