{"thread":{"id":"1413","subject":"bisect gives strange answer","startedAt":"2005-08-04T04:53:21Z","lastAt":"2005-08-07T17:06:19Z","messageCount":11,"participants":["Sanjoy Mahajan","Junio C Hamano","Greg KH","Dave Jones","Sam Ravnborg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6789","messageId":"E1E0XjN-000102-Un@approximate.corpus.cam.ac.uk","threadId":"1413","inReplyTo":null,"subject":"bisect gives strange answer","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2005-08-04T04:53:21Z","receivedAt":"2005-08-04T04:53:21Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"I have been having lots of fun using 'git bisect' to find the commit\nthat broke S3 wake on my laptop. But in its last step it gives an\nanswer that cannot be right. I had not used git until now, so I may be\nmissing something obvious: Corrections will be gratefully received. I'm\nusing git from git-2005-08-03.tar.gz on i386 (TP 600X, Debian testing).\n\nBefore using git bisect, I had tested enough to know that 2.6.13-rc1 was\nfine and 2.6.13-rc2-git1 was not (it would sleep but waking up would\nhang). So I compiled all the 2.6.13-rc1-git* snapshots and found that\n2.6.13-rc1-git7 was the last one that worked, and 2.6.13-rc2-git1 was\nthe first to fail (see \nif you are curious about the bug itself).\n\nTime to use 'git bisect' to find where in between the S3 wake got\nbroken. I'll give all the commands I did so you can (hopefully!)\nreproduce the problem.\n\nI began by following the useful directions at\n to download the 2.6 repository:\n\nrepo=rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\ngit clone $repo linux-2.6\ncd linux-2.6 \nrsync -a --verbose --stats --progress $repo/ .git/\n\nThen I binary searched, compiling and testing, until bisect told me I\nwas done. Here's the output of a script (run with #!/bin/bash -x) that\nreproduces the problem in the clean archive made above.\n\n======================================================================\n+ git checkout\n+ git bisect reset\n+ git bisect start\n+ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3 # 2.6.13-rc1-git7\n+ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6 # 2.6.13-rc2-git1\nBisecting: 42 revisions left to test after this\n+ cat .git/HEAD\nb2f571026594884e7a2a3f8bc6ad5c92e0703330\n+ git bisect good\nBisecting: 30 revisions left to test after this\n+ cat .git/HEAD\n450008b5a62bb09445ae05c4d01d510386c9435d\n+ git bisect good\nBisecting: 15 revisions left to test after this\n+ cat .git/HEAD\na9df3597fec5472d0840fbfdc2a3fac5268f7d08\n+ git bisect bad\nBisecting: 8 revisions left to test after this\n+ cat .git/HEAD\n28e8c3ad9464de54a632f00ab3df88fa5f4652d1\n+ git bisect bad\nBisecting: 4 revisions left to test after this\n+ cat .git/HEAD\nc774e93e2152d0be2612739418689e6e6400f4eb\n+ git bisect bad\nBisecting: 2 revisions left to test after this\n+ cat .git/HEAD\nb4634484815e1879512a23e4f59eef648135c30a\n+ git bisect bad\nb4634484815e1879512a23e4f59eef648135c30a is first bad commit\ndiff-tree b4634484815e1879512a23e4f59eef648135c30a (from 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)\nAuthor: Greg KH \nDate: Wed Jul 6 08:51:03 2005 -0700\n\n [PATCH] Fix bt87x.c build problem\n \n Missing forward declaration\n \n Signed-off-by: Greg Kroah-Hartman \n Signed-off-by: Linus Torvalds \n\n:040000 040000 5717e17e384b0b40e409966403e2b8dfdab615a9 4ba0c028e80bf81c5c782e9047bd484a1eeadca4 M\tsound\n======================================================================\n\nThe answer makes no sense since my .config doesn't use the bt87x driver\n(the TP600X uses a snd-cs46xx). To be sure, I checked the diff with\n\n git diff 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737..b4634484815e1879512a23e4f59eef648135c30a\n\nThe commit changed only sound/pci/bt87x.c\n\nI do believe this line at the end of the bisection:\n\n b4634484815e1879512a23e4f59eef648135c30a is first bad commit\n\nBut \n diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)\n\ncannot be right. Where did 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737\ncome from? The last good commit was\n 450008b5a62bb09445ae05c4d01d510386c9435d \nso shouldn't bisect (if there's really only 1 commit in left now) say\n\n diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 450008b5a62bb09445ae05c4d01d510386c9435d)\n\n $ git diff 450008b5a62bb09445ae05c4d01d510386c9435d \\\n b4634484815e1879512a23e4f59eef648135c30a \\\n | grep 'diff --git' | awk '{print $3}'\n\nproduces this list of changed files (I'm sure there's an easier way):\n\na/arch/arm/kernel/armksyms.c\na/arch/arm/mach-ixp4xx/common-pci.c\na/arch/arm/mach-ixp4xx/coyote-setup.c\na/arch/arm/mach-ixp4xx/ixdp425-setup.c\na/arch/arm/mm/proc-v6.S\na/drivers/pci/pci-driver.c\na/include/asm-arm/arch-ixp4xx/io.h\na/sound/pci/bt87x.c\n\nI suspect that bisect jumped the gun at the end, and that there are a\nfew more revisions to test. Maybe the revision tree structure gets a\nbit complicated and breaks an implicit linearity assumption in bisect?\n\nProbably 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is the commit just\nbefore b4634484815e1879512a23e4f59eef648135c30a (the first one I know to\nbe bad), and I'm guessing that 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737\nis bad too.\n\nThe suspect change is probably to drivers/pci/pci-driver.c since all the\nother changed files are the unused bt87x sound driver or are for the arm\narchitecture. Here is that diff:\n\ndiff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c\n--- a/drivers/pci/pci-driver.c\n+++ b/drivers/pci/pci-driver.c\n@@ -17,13 +17,13 @@\n * Dynamic device IDs are disabled for !CONFIG_HOTPLUG\n */\n \n+#ifdef CONFIG_HOTPLUG\n+\n struct pci_dynid {\n \tstruct list_head node;\n \tstruct pci_device_id id;\n };\n \n-#ifdef CONFIG_HOTPLUG\n-\n /**\n * store_new_id\n *\n\n\nBut whether moving back the CONFIG_HOTPLUG fixes my S3 wake is another\nstory, one for the acpi-devel list (once I do the experiment).\n"},{"id":"6792","messageId":"7v8xzi42bm.fsf@assigned-by-dhcp.cox.net","threadId":"1413","inReplyTo":"E1E0XjN-000102-Un@approximate.corpus.cam.ac.uk","subject":"Re: bisect gives strange answer","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-04T06:57:01Z","receivedAt":"2005-08-04T06:57:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sanjoy Mahajan writes:\n\n> + git bisect bad\n> Bisecting: 2 revisions left to test after this\n> + cat .git/HEAD\n> b4634484815e1879512a23e4f59eef648135c30a\n> + git bisect bad\n> b4634484815e1879512a23e4f59eef648135c30a is first bad commit\n> diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)\n> The answer makes no sense since my .config doesn't use the bt87x driver\n> (the TP600X uses a snd-cs46xx). To be sure, I checked the diff with\n>\n> git diff 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737..b4634484815e1879512a23e4f59eef648135c30a\n>\n> The commit changed only sound/pci/bt87x.c\n>\n> I do believe this line at the end of the bisection:\n>\n> b4634484815e1879512a23e4f59eef648135c30a is first bad commit\n>...\n> I suspect that bisect jumped the gun at the end, and that there are a\n> few more revisions to test.\n\nThank you for a very useful reproduction recipe. I think this\nis my bug. Could you try this please?\n\n------------\ndiff --git a/git-bisect-script b/git-bisect-script\n--- a/git-bisect-script\n+++ b/git-bisect-script\n@@ -107,8 +107,8 @@ bisect_next() {\n \trev=$(eval \"git-rev-list --bisect $good $bad\") || exit\n \tnr=$(eval \"git-rev-list $rev $good\" | wc -l) || exit\n \tif [ \"$nr\" -le \"1\" ]; then\n-\t echo \"$bad is first bad commit\"\n-\t git-diff-tree --pretty $bad\n+\t echo \"$rev is first bad commit\"\n+\t git-diff-tree --pretty $rev\n \t exit 0\n \tfi\n \techo \"Bisecting: $nr revisions left to test after this\"\n"},{"id":"6793","messageId":"E1E0a4e-0000vu-69@approximate.corpus.cam.ac.uk","threadId":"1413","inReplyTo":"7v8xzi42bm.fsf@assigned-by-dhcp.cox.net","subject":"Re: bisect gives strange answer","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2005-08-04T07:23:28Z","receivedAt":"2005-08-04T07:23:28Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"> Could you try this please?\n\nThanks, it now finishes with the diff that I expected:\n\n3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit\ndiff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461)\nAuthor: Greg KH \nDate: Wed Jul 6 09:09:38 2005 -0700\n\n [PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem\n \n Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled\n in 2.6.13-rc2.\n \n Signed-off-by: Greg Kroah-Hartman \n Signed-off-by: Linus Torvalds \n\n:040000 040000 93e93c4d8e88d6e05e815261f96ab38376c92809 b9cbda6dd88aeca51031d36e00f396e7091fd54c M\tdrivers\n\n\nThe full run is included below.\n\n-Sanjoy\n\n`A society of sheep must in time beget a government of wolves.'\n - Bertrand de Jouvenal\n\n\n+ git bisect reset\n+ git bisect start\n+ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3\n+ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6\nBisecting: 42 revisions left to test after this\n+ cat .git/HEAD\nb2f571026594884e7a2a3f8bc6ad5c92e0703330\n+ git bisect good\nBisecting: 30 revisions left to test after this\n+ cat .git/HEAD\n450008b5a62bb09445ae05c4d01d510386c9435d\n+ git bisect good\nBisecting: 15 revisions left to test after this\n+ cat .git/HEAD\na9df3597fec5472d0840fbfdc2a3fac5268f7d08\n+ git bisect bad\nBisecting: 8 revisions left to test after this\n+ cat .git/HEAD\n28e8c3ad9464de54a632f00ab3df88fa5f4652d1\n+ git bisect bad\nBisecting: 4 revisions left to test after this\n+ cat .git/HEAD\nc774e93e2152d0be2612739418689e6e6400f4eb\n+ git bisect bad\nBisecting: 2 revisions left to test after this\n+ cat .git/HEAD\nb4634484815e1879512a23e4f59eef648135c30a\n+ git bisect bad\n3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit\ndiff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461)\nAuthor: Greg KH \nDate: Wed Jul 6 09:09:38 2005 -0700\n\n [PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem\n \n Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled\n in 2.6.13-rc2.\n \n Signed-off-by: Greg Kroah-Hartman \n Signed-off-by: Linus Torvalds \n\n:040000 040000 93e93c4d8e88d6e05e815261f96ab38376c92809 b9cbda6dd88aeca51031d36e00f396e7091fd54c M\tdrivers\n"},{"id":"6795","messageId":"20050804172635.GA14144@kroah.com","threadId":"1413","inReplyTo":"E1E0a4e-0000vu-69@approximate.corpus.cam.ac.uk","subject":"Re: bisect gives strange answer","fromName":"Greg KH","fromEmail":"greg@kroah.com","sentAt":"2005-08-04T17:26:35Z","receivedAt":"2005-08-04T17:26:35Z","isPatch":false,"sender":{"key":"greg@kroah.com","avatar":"https://gravatar.com/avatar/5bb5aa0cc2e01c00ec899d11130c07796bc186e465bae57bc34873b13b72c7c8?d=mp&s=160"},"body":"On Thu, Aug 04, 2005 at 03:23:28AM -0400, Sanjoy Mahajan wrote:\n> > Could you try this please?\n> \n> Thanks, it now finishes with the diff that I expected:\n> \n> 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is first bad commit\n> diff-tree 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 (from a18bcb7450840f07a772a45229de4811d930f461)\n> Author: Greg KH \n> Date: Wed Jul 6 09:09:38 2005 -0700\n> \n> [PATCH] PCI: fix !CONFIG_HOTPLUG pci build problem\n> \n> Here's a patch to fix the build issue when CONFIG_HOTPLUG is not enabled\n> in 2.6.13-rc2.\n> \n> Signed-off-by: Greg Kroah-Hartman \n> Signed-off-by: Linus Torvalds \n\nBy any chance, is this patch causing you problems?\n\nJust curious :)\n\ngreg k-h\n"},{"id":"6796","messageId":"E1E0jiv-0003c4-00@skye.ra.phy.cam.ac.uk","threadId":"1413","inReplyTo":"20050804172635.GA14144@kroah.com","subject":"Re: bisect gives strange answer","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2005-08-04T17:41:41Z","receivedAt":"2005-08-04T17:41:41Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"> By any chance, is this patch causing you problems?\n\nNo, sadly. But I had hopes! As I think about it more, there's no way\nit could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG\nwould not change anything (for those who don't know the patch, it is\nappended below). \n\nMy latest theory is that I fed bisect incorrect good/bad data.\nPerhaps If I had checked out and compiled those intermediate versions\nfrom scratch, each version in a separate directory, then I would have\ngot different answers. Two possible reasons:\n\n1. The kernel Makefiles ar do not understand every subtle dependency.\n So they might get confused by updating to different tree states (as\n the bisect progresses) because those updates change Makefiles and\n include files. In other words, I should have done 'make clean' or\n 'make mrproper' before each kernel compile.\n\n2. git-bisect-script doesn't use -f when it does 'git checkout', so\n files that should be updated are not. Right now I'm in the middle\n of recollecting the data with git-bisect-script using -f in all\n uses of git checkout (unless that is a really silly idea).\n\n-Sanjoy\n\n\ngit diff a18bcb7450840f07a772..3d3c2ae1101c1f2dff7e2f9d514769779dbd2737\ndiff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c\n--- a/drivers/pci/pci-driver.c\n+++ b/drivers/pci/pci-driver.c\n@@ -17,13 +17,13 @@\n * Dynamic device IDs are disabled for !CONFIG_HOTPLUG\n */\n \n-#ifdef CONFIG_HOTPLUG\n-\n struct pci_dynid {\n\tstruct list_head node;\n\tstruct pci_device_id id;\n };\n \n+#ifdef CONFIG_HOTPLUG\n+\n /**\n * store_new_id\n *\n"},{"id":"6797","messageId":"20050804182717.GA2241@redhat.com","threadId":"1413","inReplyTo":"E1E0jiv-0003c4-00@skye.ra.phy.cam.ac.uk","subject":"Re: bisect gives strange answer","fromName":"Dave Jones","fromEmail":"davej@redhat.com","sentAt":"2005-08-04T18:27:17Z","receivedAt":"2005-08-04T18:27:17Z","isPatch":false,"sender":{"key":"davej@redhat.com","avatar":null},"body":"On Thu, Aug 04, 2005 at 06:41:41PM +0100, Sanjoy Mahajan wrote:\n > > By any chance, is this patch causing you problems?\n > \n > No, sadly. But I had hopes! As I think about it more, there's no way\n > it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG\n > would not change anything (for those who don't know the patch, it is\n > appended below). \n > \n > My latest theory is that I fed bisect incorrect good/bad data.\n > Perhaps If I had checked out and compiled those intermediate versions\n > from scratch, each version in a separate directory, then I would have\n > got different answers. Two possible reasons:\n\nErrrrm, if you don't compile/test those intermediate versions,\nhow do you know whether to tag it good/bad ?\n\n\t\tDave\n"},{"id":"6798","messageId":"E1E0kVw-0003re-00@skye.ra.phy.cam.ac.uk","threadId":"1413","inReplyTo":"20050804182717.GA2241@redhat.com","subject":"Re: bisect gives strange answer","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2005-08-04T18:32:20Z","receivedAt":"2005-08-04T18:32:20Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"> Errrrm, if you don't compile/test those intermediate versions,\n> how do you know whether to tag it good/bad ?\n\nSorry, I wrote this part carelessly: \"If I had checked out and\ncompiled those intermediate versions from scratch...\"\n\nI meant to emphasize the 'from scratch'. I did check out and compile\nthe versions, but I didn't compile from scratch. i.e. I just took\nwhatever directory tree I got after\n\n git bisect good\nor\n git bisect bad\n\nand then did 'make -j 4'. Perhaps I should have done\n\n make clean \n \n make -j 4\n\nto be really sure that every file that needed recompilation got\nrecompiled.\n\n-Sanjoy\n"},{"id":"6800","messageId":"7v8xzh1r1v.fsf@assigned-by-dhcp.cox.net","threadId":"1413","inReplyTo":"20050804182717.GA2241@redhat.com","subject":"Re: bisect gives strange answer","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-04T18:43:24Z","receivedAt":"2005-08-04T18:43:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dave Jones writes:\n\n> Errrrm, if you don't compile/test those intermediate versions,\n> how do you know whether to tag it good/bad ?\n\nI think Sanjoy is saying that they _were_ tested, and suspects\nthat bisect didn't leave the right versions of the files in the\nwork tree, so what was compiled and tested were not what bisect\nwanted to get tested. This is theory #2 in Sanjoy's post:\n\n>> 2. git-bisect-script doesn't use -f when it does 'git checkout', so\n>> files that should be updated are not. Right now I'm in the middle\n>> of recollecting the data with git-bisect-script using -f in all\n>> uses of git checkout (unless that is a really silly idea).\n\nI find this explanation quite plausible, in case it is all my\nfault and I apologize for wasting kernel developers' time.\n"},{"id":"6801","messageId":"20050804192838.GB26714@mars.ravnborg.org","threadId":"1413","inReplyTo":"E1E0jiv-0003c4-00@skye.ra.phy.cam.ac.uk","subject":"Re: bisect gives strange answer","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-08-04T19:28:38Z","receivedAt":"2005-08-04T19:28:38Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> \n> 1. The kernel Makefiles ar do not understand every subtle dependency.\n> So they might get confused by updating to different tree states (as\n> the bisect progresses) because those updates change Makefiles and\n> include files. In other words, I should have done 'make clean' or\n> 'make mrproper' before each kernel compile.\n\nIf you see any sort of evidence that this would hold true I really like\nto know.\nThe current build system is only known to fail if a changed file gets a\ntimestamp that is not equal to 'now'. Some braindead SCM uses the\ntimestamp of the chekin.\n\nThere has been put a tremendous effort in tracking each and every subtle\ndependeny - and if something is missing then it ought to be fixed.\n\n\tSam\n"},{"id":"6854","messageId":"E1E14Hj-0001Nt-00@skye.ra.phy.cam.ac.uk","threadId":"1413","inReplyTo":"20050804192838.GB26714@mars.ravnborg.org","subject":"Re: bisect gives strange answer","fromName":"Sanjoy Mahajan","fromEmail":"sanjoy@mrao.cam.ac.uk","sentAt":"2005-08-05T15:38:59Z","receivedAt":"2005-08-05T15:38:59Z","isPatch":false,"sender":{"key":"sanjoy@mrao.cam.ac.uk","avatar":null},"body":"> If you see any sort of evidence that this would hold true I really like\n> to know.\n\nI haven't found any evidence. When I rebuilt the kernels from scratch\n(exporting them into an empty directory using cg-export), I got\nreliable data and bisected down to a patch that probably was a problem.\n\nI will redo those tests but rebuilding in place after each bisection\n(with -f added to all the git checkout uses in git-bisect-script) and\nsee whether I get the same results. If I don't, it could be due to\ngit or git-bisect (but not so likely with the -f switch) or to the\nbuild system. Will keep you and Junio posted.\n\n-Sanjoy\n"},{"id":"6905","messageId":"7vvf2hy8vo.fsf@assigned-by-dhcp.cox.net","threadId":"1413","inReplyTo":"E1E14Hj-0001Nt-00@skye.ra.phy.cam.ac.uk","subject":"Re: bisect gives strange answer","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-07T17:06:19Z","receivedAt":"2005-08-07T17:06:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sanjoy Mahajan writes:\n\n> I will redo those tests but rebuilding in place after each bisection\n> (with -f added to all the git checkout uses in git-bisect-script) and\n> see whether I get the same results. If I don't, it could be due to\n> git or git-bisect (but not so likely with the -f switch) or to the\n> build system. Will keep you and Junio posted.\n\nI thought the lack of '-f' was a plausible explanation, but here\nis what I just did. The same bisect sequence in your example,\nmaking sure the state of working tree matches what the commit\nbeing tested:\n\n $ git bisect start\n $ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3\n $ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6\n Bisecting: 42 revisions left to test after this\n $ cat .git/HEAD\n b2f571026594884e7a2a3f8bc6ad5c92e0703330\n $ git bisect good; cat .git/HEAD; git-diff-cache -r bisect\n Bisecting: 30 revisions left to test after this\n 450008b5a62bb09445ae05c4d01d510386c9435d\n $ git bisect good; cat .git/HEAD; git-diff-cache -r bisect\n Bisecting: 15 revisions left to test after this\n a9df3597fec5472d0840fbfdc2a3fac5268f7d08\n $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect\n Bisecting: 8 revisions left to test after this\n 28e8c3ad9464de54a632f00ab3df88fa5f4652d1\n $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect\n Bisecting: 4 revisions left to test after this\n c774e93e2152d0be2612739418689e6e6400f4eb\n $ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect\n Bisecting: 2 revisions left to test after this\n b4634484815e1879512a23e4f59eef648135c30a\n\nSo it does not appear to me that lack of '-f' is a problem.\nWithout the flag, checkout does \"read-tree -m -u\" which means to\nupdate the working tree to match the new tree being read (this\nincludes the removal of files from the working tree that were\nregistered in the original index file that are not in the next\ntree).\n"}]}