On Monday 28 March 2011 20:22:42 john stultz wrote:
> On Mon, 2011-03-28 at 00:06 -0400, Nicolas Pitre wrote:
> > Given those issues, I decided to rebuild the linaro-2.6.38 branch from
> > scratch to see where that would bring me. And as could be expected, the
> > result looks nicer and it is much easier to work with than the current
> > tree. For example, this allowed me to merge the latest OMAP support
> > from mainline as is, including the latest fixes, without any need for
> > backport work nor major conflict resolution. Another advantage is that
> > the commit SHA1 references are now identical in most cases to what can
> > be found into mainline.
>
> Oof. So this will cause some pain with the Linaro + Android kernel tree,
> as it is a consumer of the Linaro 2.6.38 tree.
>
> I could throw out the old tree and re-merge the new Linaro tree with the
> current Android tree and our fixes, but that could cause grief for folks
> pulling from the current tree.
>
> Maybe as an alternative solution: you could diff the new tree from the
> old tree and apply those chunks to the old tree. That would get us to
> the same spot, but without the rebase. The patch log won't be great, but
> that could be fixed up when you open up the 2.6.39 branch (maybe naming
> it 2.6.39-rc would be best to avoid the same issue in the future).
>
>
> But either way, I think the Android tree could probably could survive
> it.
If you worry about the users of the Android tree more than the
git history of it, there may be another option: Take the diff between
the old and the new linaro-2.6.38 and apply that on the Android
tree. After you have fixed up all conflicts you get from that,
do a pull from the new tree and solve ignore all conflicts by reverting
them in the merge.
That way, you have a tree that your downstream can pull.
Arnd
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
