Question

I have a set of changes which work perfectly against a certain linux version, say 2.6.25.4.

I have a git tree, and created a tracking branch vanilla-2.6.25.4 from the tag v2.6.25.4. I created a branch from this called my-changes-2.6.25.4, and did all my work.

Now, I would like to rebase my work on top of an arbitrary newer version of Linux. Say 2.6.28.9. What is the optimal git work flow to achieve this?

I know how to create a new branch from 2.6.28.9, but doing something like ‘git merge my-changes-2.6.25.4’ gives all kinds of conflicts from other things that I’m not interested in. This seems broken anyways.

I tried creating a new branch from my working my-changes-2.6.25.4, and doing git rebase 2.6.28.9, assuming this would take my changes from 2.6.25.4 and apply them on top of 2.6.28.9, but this gave me tons of conflicts that weren’t related to anything I’ve changed.

I’m not sure what is the proper way to do this. I’m using the stable linux tree http://www.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git, and I think some of the problems may stem from the fact that the versioned tags, v2.6.x.y aren’t all from the same lineage.

Does anyone know how to do this properly? Extra credit for devising a way to automatically move forward as far as possible through binary search to find the next place where Linux broke my code by changing an interface, but I imagine once I know what I am actually trying to do I can automate it myself.

Answer 1

Your second approach sounds about right— but how did you invoke rebase? You need to tell it you’re changing which is your base revision. I think you need something like

# on changes-2.6.25.4
# make new branch
git checkout -b changes-2.6.28.9
# double-check local changes to transport
git log --pretty=oneline v2.6.25.4..
# transport changes to be against new base
git rebase --onto v2.6.28.9 v2.6.25.4
# should now have the same changes
git log --pretty=oneline v2.6.28.9..

Another possibility to avoid getting dumped out in the middle of a rebase is to take your list of local changes and manually add them to a new branch based on v2.6.28.9 using the “git cherry-pick” command. Actually this is effectively the same as rebasing, but in a sense leaves you more in control of what you’re doing.

I think your reasoning as to why this is a problem is correct: v2.6.28.9 is not a descendant of v2.6.25.4- so by default rebase would try to include all the changes in v2.6.26..v2.6.25.4 as well as yours, if you simply did “git rebase v2.6.28.9”. The one-argument rebase will try to get your local changes as “git log $1..HEAD” and then apply those back on top of “$1”- so you can see this only makes sense if the arg to rebase is a branch which has been updated. If you rebase off the same tag as you did before, nothing happens. If you rebase off a different tag, you get other people’s changes mixed in with yours. You need to rebase off one tag onto another.