Status of the linaro-2.6.38 kernel
nicolas.pitre at linaro.org
Mon Mar 28 19:33:21 UTC 2011
On Mon, 28 Mar 2011, john stultz wrote:
> On Mon, 2011-03-28 at 00:06 -0400, Nicolas Pitre wrote:
> > Given those issues, I decided to rebuild the linaro-2.6.38 branch from
> > scratch to see where that would bring me. And as could be expected, the
> > result looks nicer and it is much easier to work with than the current
> > tree. For example, this allowed me to merge the latest OMAP support
> > from mainline as is, including the latest fixes, without any need for
> > backport work nor major conflict resolution. Another advantage is that
> > the commit SHA1 references are now identical in most cases to what can
> > be found into mainline.
> Oof. So this will cause some pain with the Linaro + Android kernel tree,
> as it is a consumer of the Linaro 2.6.38 tree.
> I could throw out the old tree and re-merge the new Linaro tree with the
> current Android tree and our fixes, but that could cause grief for folks
> pulling from the current tree.
> Maybe as an alternative solution: you could diff the new tree from the
> old tree and apply those chunks to the old tree. That would get us to
> the same spot, but without the rebase. The patch log won't be great, but
> that could be fixed up when you open up the 2.6.39 branch (maybe naming
> it 2.6.39-rc would be best to avoid the same issue in the future).
Well, yeah. Due to some unfortunate timing, I opened the linaro-2.6.38
earlier than I had wished. I normally open a new tree only when
the equivalent upstream version is out.
Let's see... I currently have:
$ git diff --shortstat old_linaro-2.6.38..new_linaro-2.6.38
805 files changed, 55412 insertions(+), 25203 deletions(-)
$ git diff --shortstat old_linaro-2.6.38..v2.6.38
966 files changed, 15985 insertions(+), 40994 deletions(-)
$ git diff --shortstat v2.6.38..new_linaro-2.6.38
1586 files changed, 93151 insertions(+), 37933 deletions(-)
Given that I want to preserve the history, what I can do is to apply the
old->new diff to the old branch as this is the smallest diff, and then
merge the new branch on top to tie the new history to it. That should
remove the need for any rebase in the technical sense of the word, but
that would still cause quite a road bump next time you pull that. Is it
worth it? To me this doesn't make a huge difference.
> But either way, I think the Android tree could probably could survive
I guess this depends on the nature of the consumers you have for your
More information about the linaro-kernel