linux-kernel - Re: merging other repos into linux-2.6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Oct 2008 16:28:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <greg@...ah.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: merging other repos into linux-2.6

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/