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