On Wed, 14 Jul 2021, Pavel Machek wrote: > Hi! > > > > > On 14. 07. 21, 10:15, Holger Kiehl wrote: > > > >> Yes, will try to do that. I think it will take some time ... > > > >> > > > > Hmm, I am doing something wrong? > > > > > > No, you are not: -rcs are not tagged. > > > > > > > git clone > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > > linux-5.13.y > > > > cd linux-5.13.y/ > > > > git tag|grep v5.13 > > > > v5.13 > > > > v5.13-rc1 > > > > v5.13-rc2 > > > > v5.13-rc3 > > > > v5.13-rc4 > > > > v5.13-rc5 > > > > v5.13-rc6 > > > > v5.13-rc7 > > > > v5.13.1 > > > > > > > > There is no v5.13.2-rc1. It is my first time with 'git bisect'. Must be > > > > doing something wrong. How can I get the correct git kernel rc version? > > > > > > So just bisect v5.13.1..linux-5.13.y. > > > > > But what do I say for bad? > > > > git bisect bad linux-5.13.y > > error: Bad rev input: linux-5.13.y > > > > Just saying: > > > > git bisect bad > > git bisect good v5.13.1 > > Bisecting: a merge base must be tested > > [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13 > > > > If I read this correctly it now set v5.13 as bad and v5.13.1 as good. > > How to set the correct bad? > > You can use hashes instead of symbolic revisions, and that may be > easier. I suspect you want to say "git bisect bad > origin/linux-5.13.y". You can also just do git show and note the hash. > > There's other option: git bisect can be quite confusing, but you are > searching for a bug in linear history, so you can just git log > --pretty=oneline into a file, then do the binary search > manually. Should be 10 steps or so... > Thanks! That 'git bisect bad origin/linux-5.13.y' got me going! Holger
