Re: merging other repos into linux-2.6

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 30 Oct 2008, Greg KH wrote:
> 
> But as for the 'bisectability' at one point in the merge, you will be
> adding a stand-alone driver into the kernel itself.  So for anyone
> traversing down that path, all you would be building would be the driver
> itself, the whole rest of the kernel is "gone".

Right. This was exactly what happened initially in the btrfs thing. And it 
was horrid.

It was horrid because it was totally unexpected for users, and causes huge 
churn and confusion when trying to check out a totally different directory 
layout (and git won't remove the old *.o files, so trust me, it _will_ be 
confusing).

But it was horrid also because if you do it the straightforward but stupid 
way (the way that git definitely does support) by using a "subdirectory 
merge" to merge the individual driver into a new location, it also makes 
the history almost totally useless. Suddenly trivial things like

	git log drivers/xyz/file.c

don't work well at all any more, because in the old history it will all be 
under the pathname "file.c" _without_ the drivers/xyz/ part. And the 
merge diff will be just one huge mess.. 

So yes, git can do it that way, but the end result is so horrible as to be 
worse than not importing the history at all!

What I got Chris Mason to do was to run

	git filter-branch --index odd-script-goes-here

with that odd script looking something like:

>       #!/bin/sh
>       exists=$(git ls-files fs/btrfs/)
>       [ -z "$exists" ] &&
>               git ls-files --stage |
>               awk -F '\t' '{ print "0 0000000000000000000000000000000000000000\t" $2 "\n" $1 "\tfs/btrfs/" $2 }' |
>               git update-index --index-info

which basically does a directory rename in the branch (obviously, in this 
case into fs/btrfs, which is not what _you_ want). That way, at least the 
directory structure of the tree you merge has the same layout, and you 
don't get _that_ particular directory jumping back and forth.

Chris also merged in the history at the 2.6.26 tree (I think), so that 
while his original history had had just a stand-alone btrfs build, the end 
result was actually *totally* bisectable. Again, you should ask him about 
any other scripts he ran.

			Linus