git help needed for 2.6.34 kernel branch revival
pgf at laptop.org
Tue Aug 17 17:08:41 EDT 2010
> I'm playing with a few forward-looking ideas, one of them being
> upgrading OLPC's kernel from version 2.6.31 to 2.6.34. And always open
> to learning more about git...
> Now, a good while back, Deepak started working on a 2.6.34 branch,
> presumably forked from the 2.6.31 one that we were working on at the
> time. I'm not sure of the details of how the branch or merge was done.
> It would be nice to be able to use his work, given that it appears a
> big chunk of the work is already done. But there are 2 complications:
> 1. The 2.6.31 branch has seen a lot of developments and fixes since
> the 2.6.34 branch was created. So, we need to pull in all the recent
> changes that we've made in olpc-2.6.31.
> 2. The olpc-2.6.31 branch has merged in a few of the 2.6.31.x
> "linux-stable" releases; those familiar with kernel development will
> understand that those releases are outside of Linus' official tree
> (i.e. the 2.6.31 to 2.6.32 history in Linus' tree does *not* literally
> include the 2.6.31.x releases)
> If I try the obvious:
> git checkout olpc-2.6.34-dev
> git merge olpc-2.6.31
> then we end up pulling in all of the linux-stable-2.6.31 changes into
> the 2.6.34 branch. For the majority there will be no problem. But now
> and then, fixes are made in -stable which differ from the equivalent
> fixes that end up in mainline. For example
> (note how it says "fixed in a different way")
would it work better to merge each of the the -stable kernels
in turn? because then you'd probably get the undo of the -stable
change along with the mainline change that supercedes it. but that
might not work, and it would be a lot of merges.
> So I end up with a large task on my hands (finding all these little
> differences and figuring out the right course of action), and a
> resultant kernel that I don't really trust.
> Another option could be to undo the merges of the linux-stable trees
> from olpc-2.6.31. But I don't know how.
> What's the best course of action?
> Perhaps the best answer is "start again with a 2.6.34 rebase". I can
> use this command to determine all the OLPC commits that aren't in
> mainline or the linux-stable merges:
> git log --pretty=oneline 120f68c4..olpc-2.6.31
> (120f68c4 is the 126.96.36.199 linux-stable release commit, the last
> 2.6.31-stable release merged into olpc-2.6.31)
> Maybe this is the best course of action? The headache is that we're
> looking at 399 commits.
> On a separate note, I guess it would make sense for OLPC to define a
> policy where -stable updates are not brought into the OLPC kernel
> tree. This would avoid this headache in future, as the history would
> flow consistent with Linus' tree.
> Devel mailing list
> Devel at lists.laptop.org
paul fox, pgf at laptop.org
More information about the Devel