On Mon, Sep 9, 2019 at 12:25 PM Alexander Kapshuk alexander.kapshuk@gmail.com wrote:
On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell sfr@canb.auug.org.au wrote:
Hi,
On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell sfr@canb.auug.org.au wrote:
If you are bisecting linux-next, I will suggest bisecting between the stable branch on linux-next (which is just Linus' tree when I started that day) and the top of the first linux-next that fails. (Assuming that the stable branch is good).
Actually (since you won't be bisecting the latest linux-next), you probably want to use
git merge-base stable next-20190903 (or whatever linux-next you are bisecting)
as your first good commit (assuming it id good :-)).
-- Cheers, Stephen Rothwell
Hi Stephen,
Thanks very much for the tips. I'll go ahead and give those a try.
Yeah this should help, but in general, due to our non-linear history, git bisect can jump around quite a bit. Especially if you only look at dates. Also due to our non-linear history, it sometimes needs to test you a merge-base, to figure out which part of the history it needs to chase for the bad commit. So all normal, but the hint above should help.
Also, you don't need to restart git bisect, you can just tell it about any good/bad commit you tested with
$ git bisect good|bad $sha1
The more git knows, the quicker it should find the bad commit.
Cheers, Daniel