On Mon, 28 Mar 2011, 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.
Hmmm... Well...
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).
Well, yeah. Due to some unfortunate timing, I opened the linaro-2.6.38 earlier than I had wished. I normally open a new tree only when the equivalent upstream version is out.
Let's see... I currently have:
$ git diff --shortstat old_linaro-2.6.38..new_linaro-2.6.38 805 files changed, 55412 insertions(+), 25203 deletions(-)
$ git diff --shortstat old_linaro-2.6.38..v2.6.38 966 files changed, 15985 insertions(+), 40994 deletions(-)
$ git diff --shortstat v2.6.38..new_linaro-2.6.38 1586 files changed, 93151 insertions(+), 37933 deletions(-)
Given that I want to preserve the history, what I can do is to apply the old->new diff to the old branch as this is the smallest diff, and then merge the new branch on top to tie the new history to it. That should remove the need for any rebase in the technical sense of the word, but that would still cause quite a road bump next time you pull that. Is it worth it? To me this doesn't make a huge difference.
But either way, I think the Android tree could probably could survive it.
I guess this depends on the nature of the consumers you have for your tree.
Nicolas