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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 11 Jan 2009 20:42:58 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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

> 
> 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.

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.

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.
As in something that is present when the average bisect user pull the tree,
and not something the user has to do afterwards.

	Sam
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ