linux-kernel - Re: current git kernel has strange problems during bisect

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:	Sun, 11 Jan 2009 11:13:30 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christian Borntraeger <borntraeger@...ibm.com>
cc:	Johannes Schindelin <Johannes.Schindelin@....de>,
	git@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: current git kernel has strange problems during bisect

On Sun, 11 Jan 2009, Christian Borntraeger wrote:
> 
> I think we should really avoid merging subtrees to the linux kernel. It 
> makes bisecting a real PITA. Furthermore, It is unlikely, but what if 
> the problem is part of the 581 changesets from btrfs?

Umm, yes? 

The thing is, btrfs was developed as an outside module. There are two 
choices: import it with history, or import it without history. The history 
is interesting, so importing _with_ it is a much nicer one. But that does 
mean that btrfs introduces into the kernel tree the same behaviour we've 
had in the git development tree for a long time - multiple root commits, 
and "independent" branches that get merged.

It's actually very natural for git, and the btrfs tree actually was 
re-done with "git filter-branch" to move all the history so that it is in 
fs/btrfs, rather than moving around from the root like the _original_ 
development was done. So it's not technically a subtree merge, it's a 
regular merge with just two different root commits - one for the original 
base kernel development, one for the original btrfs kernel development.

For bisect, it's indeed somewhat annoying, and we could have perhaps done 
some things a bit differently, but it's about the closest you can get to 
"real history" without making the first btrfs merge-point a _total_ 
disaster.

For bisect purposes, if you know you're not chasing down a btrfs issue, 
you can do

	git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8

where that commit 34353029 is the last one which has _just_ the btrfs 
files. The next commit is when it does "Merge Btrfs into fs/btrfs", and 
that one has the whole kernel tree again.

			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/