Messages in this thread | | | Date | Fri, 10 Oct 2008 20:33:32 +0200 | From | Ingo Molnar <> | Subject | Re: [git pull, take 2] x86 updates for v2.6.28, phase #2 - PAT updates |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, 10 Oct 2008, Ingo Molnar wrote: > > > > i'll re-roll the seven x86-v28-for-linus-phase3...phase10 trees as well. > > Just checking: the scheduler/rcu trees you did pull requests for > yesterday are all independent and I can pull those as-is, right?
Correct, scheduler, RCU and fastboot are all independent. To make sure i just checked the merging aspects of all of them:
sched-v28-for-linus: OK
2c10c22: Merge branch 'linus' into sched/devel 63e5c39: Merge branches 'sched/urgent' and 'sched/rt' into sched/devel 09b22a2: Merge commit 'v2.6.27-rc6' into sched/devel 7f79d85: Merge branch 'linus' into sched/devel 3cf430b: Merge branch 'linus' into sched/devel
rcu-v28-for-linus: OK
cdbb92b: Merge branch 'linus' into core/rcu b5259d9: Merge commit 'v2.6.27-rc8' into core/rcu 429b022: Merge commit 'v2.6.27-rc6' into core/rcu c4c0c56: Merge branch 'linus' into core/rcu
fastboot-v28-for-linus: OK
1562542: Merge branch 'linus' into fastboot 3588ed2: Merge branch 'linus' into fastboot f793691: Merge commit 'v2.6.27-rc6' into fastboot b676303: Merge branch 'linus' into fastboot bf015f7: Merge branch 'linus' into fastboot
the x86-v28-phase*-linus branches were all interdependent but are easy to re-propagate because all the x86 topics are -git based and while they merged the old x86/pat, they merged it before it grew that ugliness.
(and the pat2 rebase did not touch the old commits that were fine)
So it should be fine. I'm also doing rolling tests of the new branches.
In general, this is where the "extreme topical" setup rocks IMO: had this mishap happened in a linear tree i'd have had to rebase about 300 followup commits to get rid of it - that would have been quite a mess to validate. But with the topical setup it was at the end of x86/pat and only a single followup commit had to be rebased.
And bisectability bugs easily slip into extreme rebasing excercises: crossing merges cause conflicts and manual steps that are easy to mess up. I had to do such a rebase once a couple of months ago and it was very stressful and very hard to get it right.
... we are not totally immune to it though, because sometimes we still do cross-merges between topics when the conflicts just get too ugly.
So this was pretty much close to a worst-case scenario: phase2 was unacceptable due to this really stupid v1->v2 series and i had to redo the whole followup integration - but still i did not have to do _one single_ manual step in the code space itself (only on branches), so while there are new-looking merge commits with conflicts, they are all cached git-rerere entries and thus the testing status should still all be valid.
btw., that might be a Git feature request: it would be _really_ nice if instead of:
Merge branch 'linus' into x86/pat2
Conflicts: arch/x86/mm/init_64.c
git-rerere facilities created this default commit message automatically:
Merge branch 'linus' into x86/pat2
Conflicts: arch/x86/mm/init_64.c, cached 14 days ago
that way it's a lot easier to judge and trust the quality of recent merge commits. (and reduce/manage risks associated with merge mistakes)
Ingo
| |