Re: [git pull, take 2] x86 updates for v2.6.28, phase #2 - PAT updates

Ingo Molnar
2008-10-10T18:33:58Z

* 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