1

I am trying to rebase branch A onto a rather distant branch B. I don't really care for the changes that have been made in B, all that matters is that the history of B remains intact and the final checked out result of the rebase (branch A' of which B will be an ancestor) looks exactly like A.

What I tried is

git rebase B -s recursive -X theirs

Which seems to automatically resolve quite a few conflicts but unfortunately not all of them. I would really like to avoid having to step through all the conflicts manually as there are quite a lot of commits in between and the resolution is always trivial.

Is there a git command that achieves this?

DanielM
  • 1,023
  • 8
  • 18

2 Answers2

2

I'm not sure a rebase is appropriate here. If you basically want to ignore anything that B does but incorporate it into the timeline, where would the point be that undoes B's changes? You cannot do this on a commit by commit basis (which is what a rebase does) because each commit would end up empty. A possible solution would be to just revert anything that B introduced and rebase on that.

Lets assume the history is

---X---o---A
    \
     o---o---B

Create the commit that reverts anything that B did since branching off at X:

git revert A..B
# same as git revert X..B

resulting in

---X---o---A
    \
     o---o---B---B'

where B' is equivalent to X. Now the rebase

git rebase B' A

should work without any conflict resulting in a linear history

---X               o---A'
    \             /
     o---o---B---B'
musiKk
  • 14,751
  • 4
  • 55
  • 82
0

When you're in each conflicted step, you can do

git checkout --ours [filename optionally]

(Counter intuitive, I know! Check this writeup for more info)

and then follow up with the usual 

git rebase --continue
ocodo
  • 29,401
  • 18
  • 105
  • 117
  • Thanks. However, I'm afraid this is not quite what I'm looking for. Firstly, I'm quite sure I need theirs (I've already taken into account that they are, in fact, reversed). Note that I want to keep the changes from A! More importantly, what I'm trying to avoid is having to step through all the conflicts. Each of them has a trivial resolution, so it should be possible to automate this process! – DanielM Oct 16 '14 at 11:56
  • I'm having the exact same issue. From my (limited, new to using rebase) understanding, I expected "rebase --Xtheirs" (yup, opposite to what you'd do with merge) not to require any manual resolution. My understanding of what it means is that if a file has conflicting edits, choose the version from the branch you were on when you started the rebase. As you say, it does reduce the number of conflicts that have to be resolved manually. But why does it require *any* manual resolution? All you do is "checkout --theirs path; add path". Isn't that what -Xtheirs should be doing automatically?? – sootsnoot Jul 02 '15 at 03:59
  • 1
    Hi @sootsnoot this may help http://stackoverflow.com/questions/2945344/selecting-merge-strategy-options-for-git-rebase – ocodo Jul 02 '15 at 04:37
  • @Slomojo - Actually I had seen that post, but your reference to it made me read it again, and see something I missed the first time: "tree conflicts need to be resolved manually. You need to run git rebase -Xtheirs --continue (with -X repeated) ". So now I understand that the expected conflicts are tree (not content). And the reason I still saw content conflicts as I continued to rebase is that I didn't repeat the "-Xtheirs" option on each "git rebase --continue". I just assumed that since I started the rebase with "-Xtheirs", that continuing it would use the same option. Thanks very much! – sootsnoot Jul 02 '15 at 05:23
  • Right, it's a safer approach for git. Tree conflicts could be automatically resolved with a scripted approach, and everything could be reset afterwards if necesssary. – ocodo Jul 02 '15 at 05:25