On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:
On Wed, 09 Jul 2008 17:34:41 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
