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

[Nicolas Pitre]

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.,
> Ubuntu-2.6.38-8.40-ti-omap4.
> 
> 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 
base.

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.


Nicolas