[request pull] intrepid-ports - Rebased to 2.6.25.16 and patched for PS3

[Tim Gardner]

Dan Munckton wrote:
> On Mon, 2008-09-22 at 10:09 -0600, Tim Gardner wrote:
>> Dan Munckton wrote:
>>> On Mon, 2008-09-22 at 08:07 -0600, Tim Gardner wrote:
>>>> I sure get a lot of conflicts on the pull. Did you rebase correctly
>>>> first ?
>>> Umm. I'm not sure what "correctly" is. These are the steps I followed to
>>> rebase (on my blog from notes gleaned on this list):
>>>
>>> http://munckfish.net/blog/archive/2008/08/30/ubuntu-ps3-kernel-upstream-syncing/
>>>
>>> If that's the not the correct procedure please let me know and I'll get
>>> it sorted.
>> I think your method is more complicated then it needs to be. When you
>> are developing against an upstream tree (which is ubuntu-intrepid-ports
>> in this case) then you should always keep the common set of patches in
>> the same order, e.g., you rebase only when upstream rebases. Since its
>> unlikely that we'll ever rebase the ubuntu-intrepid-ports repo, then
>> your work flow should be like this:
>>
>> ) git clone git://kernel.ubuntu.com/ubuntu/ubuntu-intrepid-ports.git
>> ) Make commits to your local repo
>> ) Request pulls from your local repo
>>
>> There may still be conflicts if someone else has already made commits to
>> the same place in the code, but then you just have to resolve the
>> conflicts by hand. Given the level of activity that I've seen in this
>> repo, conflicts should be rare.
>>
>> If there are upstream patches, such as those from 2.6.25.y, then use the
>> cherry-pick method:
>>
>> git fetch
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git
>> git-cherry-pick <SHA1 ID>
>>
>> rtg
> 
> Ok I'll have to revise my work then. I'll come back once it's re-worked
> against ports as is and relevant PS3 changes are cherry picked.
> 
> Thanks
> 

One thing I neglected to point out is there are some cases where you
might want to rebase your local tree as opposed to a 'git pull origin'.
Each time you pull and then push you end up with an extra merge point in
the tree which can get kind of noisy. For example,

git checkout -f
git fetch origin
git rebase origin

This sequence gets your local tree in sync with the origin tree, and
also relocates all of your local changes such that they are on top. This
is typical of a maintainer tree wherein the maintainer is pulling
patches from other sources.

Of course, if the maintainer is also rebasing, the you'll be forced to
rebase as well. The ubuntu-intrepid-ports tree won't be rebased unless
the community presents a case for to updating to 2.6.27.

rtg
-- 
Tim Gardner tim.gardner at canonical.com