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 12:04:12 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sam Ravnborg <sam@...nborg.org>
cc:	Christian Borntraeger <borntraeger@...ibm.com>,
	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, Sam Ravnborg wrote:
> 
> The cost of moving this piece of history from one git tree to another
> git tree is that we make it harder to debug the kernel for the advanced user
> that knows how to do bisect.
> 
> It is not like this history would be lost - one just had to look
> somewhere else to find it.
> 
> That may be a bad pain/benefit ratio - time will tell.

Umm. No. 

Time is exactly what makes it useful. It will make all the downsides 
shrink, and the advantages stay.

> There should be a way to avoid such pain when bisecting without
> having to mark a semi-random (for the average person) commit as good.

Well, you don't actually have to mark that semi-random one as good either. 
What you can do is to just mark anything that _only_ contains fs/btrfs as 
good. IOW, you don't have to know the magic number - you just have to be 
told that "oh, if you only have btrfs files, and you're not actively 
bisecting a btrfs bug, just do 'git bisect good' and continue".

Yeah, you'll hit it a few times, but you don't even have to compile things 
or boot anything, so it's not actually going to be all that much slower 
than just knowing about the magic point either.

So now you can consider yourself told how to solve it. It wasn't that 
hard. And the advantage is that we have real history.

			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/