Updates to powerpc.git

Kumar Gala galak at kernel.crashing.org
Wed Jul 9 23:40:21 EST 2008


On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:

> On Wed, 09 Jul 2008 17:34:41 +1000
> Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
>
>> I've pushed some updates to my version of powerpc.git.
>>
>> The tree itself is at:
>>
>>  git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>>
>> It contains 3 branches:
>>
>>  - merge  : this is for merging with the current stable and doesn't
>>             currently contain anything interesting
>>
>>  - master : this is our current "powerpc.git" tree, it may contain
>>             various experimental stuff that may or may not go  
>> upstream
>>             or may contain dependent patches that we rely on but that
>>             are to be merged via some other tree.
>>
>>  - next   : this is the candidate stuff for linux-next and the next
>>             merge window
>>
>> (Andrew, you -may- want to pull that instead of paulus one until
>> he's back from vacation).
>>
>> Until today, master and next pointed to the same commit, which was
>> the same as paulus master and powerpc-next branches. Tonight, I've
>> pushed some patches to master that I intend to have in next, but
>> I'd like to let them sit in master for a couple of days to make sure
>> nothing is badly broken mostly and make sure I didn't screw up in
>> my various patch monkeying operations.
>
> One thing to point out is that if you decide to only select a few of
> those patches, you'll need to cherry-pick them into your next branch
> (or rebase). That means that when you pull from Linus into your master
> branch during/after the merge window, you'll get all kinds of funny
> merge commits.
>
> If you want to use your master branch as a place for experimental
> stuff, that's fine by me.  But you'll want to keep next separate from
> it so it's as "clean" as possible for those trying to track what is
> definitely going into the next release.
>
> If it were up to me (which it's not), I would have master just track
> Linus, next track what's going into the next release, and "bleeding"  
> or
> "experimental" track stuff that isn't fully vetted yet.  I might start
> doing that with my tree in the very near future.

I do something similar, but my master is a merge of linus and my next  
branch, which is roughly what I think paul did.

> Also, Paul is pretty good about not rebasing his branches when at all
> possible, and I suspect that's why his master and next were often the
> same.  It makes life lots easier for the sub-maintainers and anyone
> trying to track against the tree.  I humbly beg you to keep that  
> going.

I agree and I'm sure linus will tell you how evil it is to rebase as a  
maintainer.

- k



More information about the Linuxppc-dev mailing list