[Natty] [ti-omap4] [Pull Request]: 2.6.38.2 based updates

Bryan Wu bryan.wu at canonical.com
Wed Apr 13 23:33:33 UTC 2011


On Wed, Apr 13, 2011 at 1:01 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
> On 04/13/2011 09:47 AM, Bryan Wu wrote:
>>
>> On Wed, Apr 13, 2011 at 8:32 AM, Tim Gardner<tim.gardner at canonical.com>
>>  wrote:
>>>
>>> On 04/13/2011 07:51 AM, Bryan Wu wrote:
>>>>
>>>> git://kernel.ubuntu.com/roc/ubuntu-natty.git ti-omap4
>>>
>>> I presume that you're done rebasing against anything other then Natty
>>> master? So, it needs to be able to do that cleanly and without conflict.
>>> I
>>> just tried your branch against Ubuntu-2.6.38-8.42 and it failed.
>>>
>>
>> Because the Linaro kernel is kind of merging 2.6.38.2 patches instead
>> of rebasing, I also got rebasing issue before. Currently, in my tree:
>>
>> Linaro 2.6.38.2 from npitre (base) + Patches from Sebjan and Andy
>> Green + Our Ubuntu Delta patches (same from master) + ti-omap4 branch
>> specific patches.
>>
>> So I just added patches from 2.6.38-8.41 and -8.42 on top of our
>> Ubuntu Delta patches, then rebase ti-omap4 branch patches on it again.
>>
>> Please find the branch here:
>>
>> http://kernel.ubuntu.com/git?p=roc/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4-dev
>>
>> Thanks,
>> -Bryan
>
>
> I think for this final pass you must choose Natty master as the base, then
> rebase everything else on top. I'm assuming the only conflicts should be
> stable commits from npitre's tree (which you can skip) because Natty master
> is already up to 2.6.38.2.
>

I've tried several method to do rebase or just 'git am' patches, which
cause all kinds of conflicts. Since the Linaro kernel is not linear
and it looks like this:
2.6.38 (base) + Linaro patches part 1 + merging 2.6.38.1 + Linaro
patches part 2 + merging 2.6.38.2 + Linaro other patches. So it is
quite hard to rebase or git am now.

I generated 1633 patches which is on top of "Linux 2.6.38" release.
The very first patch of them can not be applied on top of our master
branch. I really wanna try to move these 1633 patches onto our master,
but it looks like mission impossible.

> My goal is to be able to 'git rebase master' from the ti-omap4 branch
> without conflicts.
>

I'm afraid that it is quite hard to make this. So for further SRU and
CVE updates, I have to suggest that I cherry pick those update patches
on top of our ti-omap4 instead of rebasing.

apw, we were discussing about a common git weird problem, could you
please give us some help:

in ti-omap4 tree, I just wanna get all the patches on top of a commit
which is 2.6.38 kernel release. So I found that SHA ID of that commit
and use "git format-patch -o /tmp/ SHA_ID.." to get patches. Very
strange, I got lots of patches which are not on top of that commit.

So Brad told me to do "git format-patch -1633 -o /tmp" to get 1633
patches on top of that 2.6.38 release commit.

Do you know why I failed to get right patches with the SHA ID? and if
you have time, could you take a look at my ti-omap4 branch? Is that
possible for us to rebase to master now?

Thanks a lot,
-- 
Bryan Wu <bryan.wu at canonical.com>
Kernel Developer    +86.138-1617-6545 Mobile
Ubuntu Kernel Team
Canonical Ltd.      www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com




More information about the kernel-team mailing list