[Natty] [ti-omap4] [Pull Request]: 22.214.171.124 based updates
nicolas.pitre at canonical.com
Fri Apr 15 18:36:03 UTC 2011
On Fri, 15 Apr 2011, Tim Gardner wrote:
> On 04/15/2011 12:55 AM, Andy Green wrote:
> > On 04/14/2011 06:21 PM, Somebody in the thread at some point said:
> > Hi -
> > > > Exactly, for Linaro release we found it merges several branches from
> > > > upstream and stable tree, while for TI OMAP4 patches (come from Sebjan
> > > > and Andy Green) are all linear I think.
> > >
> > > Right: I provided a re-based tree because I knew it would fit well
> > > with the Ubuntu regular strategy.
> > > But for the future I am open to look at a merge strategy if it's more
> > > convenient.
> > I'm actually carrying two branches that resolve to the same tree. My
> > master branch is using rebase against npitre's tree and allows going
> > back down the patch stack to refine the patches to feed his tree, but
> > for Bryan I keep a for-ubuntu branch with a history. I plan to, and have
> > been, adding patches as necessary to keep the diff between the two trees
> > at zero.
> > > > > There seem to be two viable approaches (to my eye), though I am fully
> > > > > open to other ideas:
> > > > >
> > > > > 1) squash the delta into a 'omap4' patch and carry that, or
> > > > > 2) accept that this is a merge based tree and develop new handling for
> > > > > this kind of tree.
> > >
> > > From my point of view, I definitely prefer option 2. But the end call
> > > belongs to you.
> > Yeah option 2 is the way forward I think.
> > -Andy
> So, this is all kind of hand wavy. How about some specifics. I've pushed
> Bryan's branch to ti-omap4 and tagged it Ubuntu-2.6.38-1208.11.
> What I expect the maintenance team to have to do is something like the
> following (note that ti-omap4 is currently behind master, Ubuntu-2.6.38-8.40
> v.s. Ubuntu-2.6.38-8.42) :
> git checkout -f ti-omap4
> git log refs/heads/master
> Decide what the last merge point was relative to master, either by inspection
> or because someone created a merge point tag, e.g.,
> git format-patch Ubuntu-2.6.38-8.40..refs/heads/master
> git am -3 0*
> Then resolve any conflicts, of which there ought to be few. Thoughts?
I don't understand why you guys are going through all this pain of
trying to linearize a Git history in order to transplant it onto another
The Linaro kernel tree is made of a lot of merges. I do merge branches
from upstream trying to keep them intact so they have the same commit
IDs and also preserve the same environment in which they were developed
and tested. For example, I did include the latest core ARM patches
simply by merging the tip of the branch that went into 2.6.39-rc1.
That branch was itself based on top of 2.6.38-rc6 or so, therefore it
was a perfect merge target for a 2.6.38 based kernel. And so on for
OMAP. Eventually I had to rebase/cherry-pick patches because they were
based on a post-2.6.38 commit. But when possible I far prefer to
perform a merge instead of a rebase.
Now the Linaro tree itself is not rebased because there are consumers of
that tree merging it into theirs. What I'd suggest is that the Ubuntu
flavor for OMAP4 should just do a merge as well. Trying to use
format-patch here won't work very well because the history in Git is
two-dimensional and cannot be linearized into a simple series of patches
across merge commits.
More information about the kernel-team