Re: [git pull] x86 changes for v2.6.27

[Ingo Molnar <mingo@elte.hu>]

* Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:

> 
> Hi,
> 
> On Monday 14 July 2008, Ingo Molnar wrote:
> > Linus,
> > 
> > Please pull the latest x86 git tree from:
> > 
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86/for-linus
> > 
> > this is our first merge window since we migrated over to a pure Git 
> > based patch management setup and integrated x86.git into the -tip tree. 
> > Going from Quilt to Git was quite hard for this 
> > 1000-patches-per-kernel-cycle tree, so please bear with us :-)
> 
> I see that fix patches are no longer folded into the guilty patch
> and it makes me a bit worried about kernel bisectability (on which
> many people depend on for hunting regressions)...
> 
> Random example (amongst many others) of what I mean:
> 
> [...]
> 
> >       x86: introduce max_low_pfn_mapped for 64-bit
> >       x86: max_low_pfn_mapped fix, #1
> >       x86: max_low_pfn_mapped fix, #2
> >       x86: max_low_pfn_mapped fix, #3
> 
> There is also a _ton_ of build fixes which could have been easily 
> folded into guilty patches.

actually, while there are indeed other examples where merging fixes 
would have made sense, those 3 above are conceptually different so we 
wanted to have them separate intentionally.

> Could you please consider adding this additional step into your 
> development process before push to Linus?

yeah, we definitely try to do that but -tip is released daily so the 
window to squash patches is small in an append-only setup. There were 2 
days between those fixes above so even if we wanted we couldnt squash 
them. The purpose of finegrained fixes is to observe the effects of the 
fixes. (sometimes the fix is worse than the bug it purports to fix)

Anyway, i think you'll see less of these in the next merge window.

	Ingo