* Ingo Molnar <mi...@kernel.org> wrote:
> Oh, that's a pleasant surprise, I didn't expect _100%_ support! :-)
>
> So I started working on this today and whipped up three of these
> movements, in a 100% scripted fashion.
>
> You can have a sneak preview at the result in this tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/toplevel
>
> ...
>
> 2515 files changed, 42476 insertions(+), 42476 deletions(-)
I have pushed out a -v2 version:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/toplevel
2523 files changed, 41304 insertions(+), 41302 deletions(-)
Changes relative to -v1:
- Fixed a bunch of bugs that light testing and light review missed:
missed rename patterns and some build bugs as well. This tree has
passed much wider testing, including cross-platform build testing, a
distro kernel package build and it also got some light boot testing,
just in case.
- Split it into finer grained steps (3 instead of 2 patches per
movement), for easier review and bisection testing:
toplevel: Move ipc/ to kernel/ipc/: move the files
toplevel: Move ipc/ to kernel/ipc/: adjust the build system
toplevel: Move ipc/ to kernel/ipc/: adjust comments and documentation
toplevel: Move sound/ to drivers/sound/: move the files
toplevel: Move sound/ to drivers/sound/: adjust the build system
toplevel: Move sound/ to drivers/sound/: adjust comments and documentation
toplevel: Move samples/ to Documentation/samples/: move the files
toplevel: Move samples/ to Documentation/samples/: adjust the build system
toplevel: Move samples/ to Documentation/samples/: adjust comments and
documentation
- The changes are now bisection safe if the #1 ('move') and #2 ('build
system') patches are squashed. The final #3 'adjust comments and
documentation' patch is non-functional in the normal kernel build.
I still kept the three steps separate, for reviewability: for many of
the changes the build system changes are lost in the noise of the
file movement diff itself. (See patch-splitting notes further below.)
- Made some of the build system changes less ad-hoc - but it's still all
100% scripted and automated. Added a SOB to the changelogs, but the
changelogs are still barebones. It's on top of Linus's latestest.
- The longer term plan outlined in my first mail is still in flux - the
'scripts/' movement is probaly a bad idea due to its widespread use.
I'm still torn about whether to do a 3-part or 2-part approach for each
directory movement:
- The problem with the 2-part approach that merges the 'pure file move'
and 'build system' patches so that the latter gets lost in the first
one in an almost unreviewable fashion. Someone would have to re-do the
git mv step and generate a diff by hand to see the build system
changes in isolation...
- The problem with the 3-part approach is that it breaks bisection
between the first two patches, although 'git bisect next' would always
step to a working commit, because the bisection build-breakage window
is only one commit wide.
So I'm slightly leaning toward the 3-part approach for the documentation
and review value - but no strong feelings either way.
Anyway, I know everyone is super busy with the merge window, will keep
posting new versions every now and then until you or Linus tells me not
to bother :-)
Thanks,
Ingo
