{"thread":{"id":"29010","subject":"git-bisect working only from toplevel dir","startedAt":"2011-11-23T14:50:34Z","lastAt":"2011-11-29T12:06:12Z","messageCount":11,"participants":["Adam Borowski","Junio C Hamano","Jeff King","Peter Baumann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"179887","messageId":"20111123145034.GB17927@angband.pl","threadId":"29010","inReplyTo":null,"subject":"git-bisect working only from toplevel dir","fromName":"Adam Borowski","fromEmail":"kilobyte@angband.pl","sentAt":"2011-11-23T14:50:34Z","receivedAt":"2011-11-23T14:50:34Z","isPatch":false,"sender":{"key":"kilobyte@angband.pl","avatar":"https://avatars.githubusercontent.com/u/48801?v=4"},"body":"Hi!\n\nThe requirement to be in the toplevel directory when calling git-bisect is\npretty infuriating. I tried to find an explanation for this, and the only\nreference I found was:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/27524/focus=27596\n\nHowever, since then, git-reset has been changed (in a81c311f). What about\nchanging git-bisect as well?\n\nA trivial patch seems to work for me, but I might have missed some corner\ncase.\n\n-- \n1KB\t\t// Yo momma uses IPv4!\n\n\nFrom 1dd5dda6a9db3d987e15784c4de24e593cc596e0 Mon Sep 17 00:00:00 2001\nFrom: Adam Borowski \nDate: Wed, 23 Nov 2011 15:08:42 +0100\nSubject: [PATCH] git-bisect: allow using it from a subdirectory.\n\nJust like git-reset, restricting it to toplevel is an annoyance, and the\nlatter has been changed in a81c311f.\n---\n git-bisect.sh | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 99efbe8..fd6ccdd 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -27,6 +27,7 @@ git bisect run ...\n Please use \"git help bisect\" to get the full man page.'\n \n OPTIONS_SPEC=\n+SUBDIRECTORY_OK=Yes\n . git-sh-setup\n . git-sh-i18n\n \n-- \n1.7.8.rc3.31.g017d1\n\n"},{"id":"179902","messageId":"7vd3cibqqe.fsf@alter.siamese.dyndns.org","threadId":"29010","inReplyTo":"20111123145034.GB17927@angband.pl","subject":"Re: git-bisect working only from toplevel dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-23T19:09:29Z","receivedAt":"2011-11-23T19:09:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Adam Borowski writes:\n\n> The requirement to be in the toplevel directory when calling git-bisect is\n> pretty infuriating. I tried to find an explanation for this, and the only\n> reference I found was:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/27524/focus=27596\n\nInteresting. It used to be that people were thankful when a command\nhappened to work from a subdirectory, and it was a minor irritation when\nsome command didn't; in the early days, everything in Git was to be used\nfrom the top-legvel.\n\n> However, since then, git-reset has been changed (in a81c311f). What about\n> changing git-bisect as well?\n>\n> A trivial patch seems to work for me, but I might have missed some corner\n> case.\n\nThanks; read and follow Documentation/SubmittingPatches the next time\nperhaps?\n\nAs to the approach, I suspect that it would be far better if it made\nworkable with cd_to_toplevel at the beginning, instead of saying\nSUBDIRECTORY_OK.\n\nAfter all, the current directory may disappear during the course of\nbisection, upon checking out a revision that did not have the directory\nyou started your bisection from.\n\n>\n> -- \n> 1KB\t\t// Yo momma uses IPv4!\n>\n> From 1dd5dda6a9db3d987e15784c4de24e593cc596e0 Mon Sep 17 00:00:00 2001\n> From: Adam Borowski \n> Date: Wed, 23 Nov 2011 15:08:42 +0100\n> Subject: [PATCH] git-bisect: allow using it from a subdirectory.\n>\n> Just like git-reset, restricting it to toplevel is an annoyance, and the\n> latter has been changed in a81c311f.\n> ---\n> git-bisect.sh | 1 +\n> 1 files changed, 1 insertions(+), 0 deletions(-)\n>\n> diff --git a/git-bisect.sh b/git-bisect.sh\n> index 99efbe8..fd6ccdd 100755\n> --- a/git-bisect.sh\n> +++ b/git-bisect.sh\n> @@ -27,6 +27,7 @@ git bisect run ...\n> Please use \"git help bisect\" to get the full man page.'\n> \n> OPTIONS_SPEC=\n> +SUBDIRECTORY_OK=Yes\n> . git-sh-setup\n> . git-sh-i18n\n"},{"id":"179903","messageId":"20111123192329.GA21630@sigill.intra.peff.net","threadId":"29010","inReplyTo":"7vd3cibqqe.fsf@alter.siamese.dyndns.org","subject":"Re: git-bisect working only from toplevel dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-23T19:23:29Z","receivedAt":"2011-11-23T19:23:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:\n\n> As to the approach, I suspect that it would be far better if it made\n> workable with cd_to_toplevel at the beginning, instead of saying\n> SUBDIRECTORY_OK.\n> \n> After all, the current directory may disappear during the course of\n> bisection, upon checking out a revision that did not have the directory\n> you started your bisection from.\n\nBut from what directory would you expect:\n\n git bisect run make\n\nto run from? If you use a GNU-ish layout with all of your code in\n\"src/\", then I can see it useful to do something like:\n\n cd src\n git bisect run make\n\nIf we cd_to_toplevel, we can remember the prefix that we started from\nand cd to it before running the user's command, but there is no\nguarantee that it actually exists. Maybe that commit should be\nconsidered indeterminate then?\n\nI dunno. I haven't thought that hard about it. But I don't think it's\nquite as simple as just telling bisect it's OK to run from a subdir.\n\n-Peff\n"},{"id":"179905","messageId":"20111123200920.GA21004@angband.pl","threadId":"29010","inReplyTo":"20111123192329.GA21630@sigill.intra.peff.net","subject":"Re: git-bisect working only from toplevel dir","fromName":"Adam Borowski","fromEmail":"kilobyte@angband.pl","sentAt":"2011-11-23T20:09:20Z","receivedAt":"2011-11-23T20:09:20Z","isPatch":false,"sender":{"key":"kilobyte@angband.pl","avatar":"https://avatars.githubusercontent.com/u/48801?v=4"},"body":"On Wed, Nov 23, 2011 at 02:23:29PM -0500, Jeff King wrote:\n> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:\n> \n> > As to the approach, I suspect that it would be far better if it made\n> > workable with cd_to_toplevel at the beginning, instead of saying\n> > SUBDIRECTORY_OK.\n> > \n> > After all, the current directory may disappear during the course of\n> > bisection, upon checking out a revision that did not have the directory\n> > you started your bisection from.\n\nNo different from git-reset or git-checkout.\n> \n> But from what directory would you expect:\n> \n> git bisect run make\n> \n> to run from? If you use a GNU-ish layout with all of your code in\n> \"src/\",\n\nIn a vast majority of cases the layout remains constant during the whole\nbisection.\n\n> then I can see it useful to do something like:\n> \n> cd src\n> git bisect run make\n> \n> If we cd_to_toplevel, we can remember the prefix that we started from\n> and cd to it before running the user's command, but there is no\n> guarantee that it actually exists.\n\nI guess, the best that can be done is going into as many path components as\npossible.\n\n> Maybe that commit should be considered indeterminate then?\n\nWhy? If you're running an automated command, then it will probably fail,\nyeah. I guess most people bisect manually though, so even in repositories\nthat do have this problem, there's someone who can test the given commit\nanyway.\n\n> I dunno. I haven't thought that hard about it. But I don't think it's\n> quite as simple as just telling bisect it's OK to run from a subdir.\n\nAt the very least, generally working with a caveat in corner cases seems to\nbe better than outright failing.\n\nIf you're paranoid, there's an option of having a config setting \"yes, I've\nread the manual why automated bisection can fail\".\n\n-- \n1KB\t\t// Yo momma uses IPv4!\n"},{"id":"179906","messageId":"20111123202643.GB6291@m62s10.vlinux.de","threadId":"29010","inReplyTo":"20111123192329.GA21630@sigill.intra.peff.net","subject":"Re: git-bisect working only from toplevel dir","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2011-11-23T20:26:43Z","receivedAt":"2011-11-23T20:26:43Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Nov 23, 2011 at 02:23:29PM -0500, Jeff King wrote:\n> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:\n> \n> > As to the approach, I suspect that it would be far better if it made\n> > workable with cd_to_toplevel at the beginning, instead of saying\n> > SUBDIRECTORY_OK.\n> > \n> > After all, the current directory may disappear during the course of\n> > bisection, upon checking out a revision that did not have the directory\n> > you started your bisection from.\n> \n> But from what directory would you expect:\n> \n> git bisect run make\n> \n> to run from? If you use a GNU-ish layout with all of your code in\n> \"src/\", then I can see it useful to do something like:\n> \n> cd src\n> git bisect run make\n> \n> If we cd_to_toplevel, we can remember the prefix that we started from\n> and cd to it before running the user's command, but there is no\n> guarantee that it actually exists. Maybe that commit should be\n> considered indeterminate then?\n> \n\nWhy not simply fail the run with exit(-1)? If the directory doesn't exist\nin an older commit (which I think is not that common) git bisect should\nsimply stop and let the user proceed. \n\nAnd yes, I find the current behaviour to forbid running git bisect from\na subdirectory slighly annoying and I'm glad somebody took a stab at it.\n\n-Peter\n"},{"id":"179909","messageId":"7vzkfma7q9.fsf@alter.siamese.dyndns.org","threadId":"29010","inReplyTo":"20111123192329.GA21630@sigill.intra.peff.net","subject":"Re: git-bisect working only from toplevel dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-23T20:45:18Z","receivedAt":"2011-11-23T20:45:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:\n>\n>> As to the approach, I suspect that it would be far better if it made\n>> workable with cd_to_toplevel at the beginning, instead of saying\n>> SUBDIRECTORY_OK.\n>> \n>> After all, the current directory may disappear during the course of\n>> bisection, upon checking out a revision that did not have the directory\n>> you started your bisection from.\n>\n> But from what directory would you expect:\n>\n> git bisect run make\n\nMy usual way to enlighten somebody is by forcing him/her to think the\nconsequences, but because you did the thinking for the OP in this thread\ninstead, it didn't work. Makes me somewhat sad ;-<.\n\n> If we cd_to_toplevel, we can remember the prefix that we started from\n> and cd to it before running the user's command, but there is no\n> guarantee that it actually exists. Maybe that commit should be\n> considered indeterminate then?\n\nYeah that sounds like a reasonable thing to do.\n\n> I dunno. I haven't thought that hard about it. But I don't think it's\n> quite as simple as just telling bisect it's OK to run from a subdir.\n\nAbsolutely. Saying SUBDIRECTORY_OK without thinking about the consequence\nthrough is a good discussion starter but is not a good patch.\n\nAlso didn't we make bisect workable in a bare repository recently? So the\nstart-up sequence has to be something more elaborate like...\n\n . git-sh-setup\n if we are in a bare repository\n then\n \t: we are happy...nothing funky needs to be done\n\telif we are not in a working tree\n\t\tbarf\n\telif we are not at the top\n \tprefix=$(git rev-parse --show-prefix)\n\t\tcd_to_toplevel\n\tfi\n\nand then inside bisect_next() you would check if $prefix exists, and go\nthere to run bisect--helper (or fail to go there and say \"cannot test\").\n"},{"id":"179915","messageId":"20111123213605.GA21835@sigill.intra.peff.net","threadId":"29010","inReplyTo":"20111123202643.GB6291@m62s10.vlinux.de","subject":"Re: git-bisect working only from toplevel dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-23T21:36:05Z","receivedAt":"2011-11-23T21:36:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 23, 2011 at 09:26:43PM +0100, Peter Baumann wrote:\n\n> > If we cd_to_toplevel, we can remember the prefix that we started from\n> > and cd to it before running the user's command, but there is no\n> > guarantee that it actually exists. Maybe that commit should be\n> > considered indeterminate then?\n> > \n> \n> Why not simply fail the run with exit(-1)? If the directory doesn't exist\n> in an older commit (which I think is not that common) git bisect should\n> simply stop and let the user proceed.\n\nThe point of \"git bisect run\" is to run unattended until we reach an\nanswer. I don't think most people would be happy with it not running to\ncome to _some_ answer (e.g., imagine checking the results of an\novernight \"bisect run\" in the morning only to find that it stopped 20\nminutes in).\n\nThat's why I think just marking the commit as indeterminate would be\nbetter; it jumps over parts of history that omit the directory, and will\ngenerally still come to a good conclusion. If it's possible to get an\nanswer, that is. It might say \"we can't come up with an answer because\nall of these commits are not testable\". But that tells you something,\ntoo: your bisection test is not a good one.\n\n> And yes, I find the current behaviour to forbid running git bisect from\n> a subdirectory slighly annoying and I'm glad somebody took a stab at it.\n\nAgreed. I often bisect by hand with two terminals, doing something like:\n\n [terminal 1]\n git bisect start ...\n make\n\n [terminal 2]\n cd t\n ./t1234-whatever -v\n\n [terminal 1]\n git bisect good|bad\n make\n\n [terminal 2]\n ./t1234-whatever\n\nAnd then want to type \"git bisect good|bad\" into terminal 2. Which\ndoesn't work, of course (yes, in this simple case I could automate the\nrunning of the test script from terminal 1; but often times it is\nsimpler to just eyeball the output during the bisection).\n\n-Peff\n"},{"id":"179916","messageId":"20111123214517.GC21835@sigill.intra.peff.net","threadId":"29010","inReplyTo":"20111123200920.GA21004@angband.pl","subject":"Re: git-bisect working only from toplevel dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-23T21:45:17Z","receivedAt":"2011-11-23T21:45:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 23, 2011 at 09:09:20PM +0100, Adam Borowski wrote:\n\n> > But from what directory would you expect:\n> > \n> > git bisect run make\n> > \n> > to run from? If you use a GNU-ish layout with all of your code in\n> > \"src/\",\n> \n> In a vast majority of cases the layout remains constant during the whole\n> bisection.\n\nAgreed. But you need to think about what happens when it does not. I\nthink marking the commit as untestable is probably best, with bisect\nbarfing a reasonable second. Accidentally marking the commit as \"bad\" is\nprobably the worst thing we could do. That would produce a subtly wrong\nbisection result.\n\n> > Maybe that commit should be considered indeterminate then?\n> \n> Why? If you're running an automated command, then it will probably fail,\n> yeah. I guess most people bisect manually though, so even in repositories\n> that do have this problem, there's someone who can test the given commit\n> anyway.\n\nIf you're not doing \"bisect run\", then it is a non-issue, no? If you\nare bisecting by hand, then \"git bisect good|bad\" will delete your\nworking directory, and probably your shell will start complaining, and\nan intelligent tester will see what happened. This is only a problem for\nautomated bisection, which does not have such a tester.\n\n> > I dunno. I haven't thought that hard about it. But I don't think it's\n> > quite as simple as just telling bisect it's OK to run from a subdir.\n> \n> At the very least, generally working with a caveat in corner cases seems to\n> be better than outright failing.\n\nTo be clear: I think this is a good feature that will help a lot of\npeople, and I don't think an uncommon corner case should prevent it from\ngoing into git. But I _do_ think we should consider what happens in the\ncorner cases and at least fail gracefully, rather than produce subtly\nwrong results.\n\n-Peff\n"},{"id":"179928","messageId":"20111124070659.GC6291@m62s10.vlinux.de","threadId":"29010","inReplyTo":"7vzkfma7q9.fsf@alter.siamese.dyndns.org","subject":"Re: git-bisect working only from toplevel dir","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2011-11-24T07:06:59Z","receivedAt":"2011-11-24T07:06:59Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Nov 23, 2011 at 12:45:18PM -0800, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > On Wed, Nov 23, 2011 at 11:09:29AM -0800, Junio C Hamano wrote:\n> >\n> >> As to the approach, I suspect that it would be far better if it made\n> >> workable with cd_to_toplevel at the beginning, instead of saying\n> >> SUBDIRECTORY_OK.\n> >> \n> >> After all, the current directory may disappear during the course of\n> >> bisection, upon checking out a revision that did not have the directory\n> >> you started your bisection from.\n> >\n> > But from what directory would you expect:\n> >\n> > git bisect run make\n> \n> My usual way to enlighten somebody is by forcing him/her to think the\n> consequences, but because you did the thinking for the OP in this thread\n> instead, it didn't work. Makes me somewhat sad ;-<.\n> \n> > If we cd_to_toplevel, we can remember the prefix that we started from\n> > and cd to it before running the user's command, but there is no\n> > guarantee that it actually exists. Maybe that commit should be\n> > considered indeterminate then?\n> \n> Yeah that sounds like a reasonable thing to do.\n> \n> > I dunno. I haven't thought that hard about it. But I don't think it's\n> > quite as simple as just telling bisect it's OK to run from a subdir.\n> \n> Absolutely. Saying SUBDIRECTORY_OK without thinking about the consequence\n> through is a good discussion starter but is not a good patch.\n> \n> Also didn't we make bisect workable in a bare repository recently? So the\n> start-up sequence has to be something more elaborate like...\n> \n> . git-sh-setup\n> if we are in a bare repository\n> then\n> \t: we are happy...nothing funky needs to be done\n> \telif we are not in a working tree\n> \t\tbarf\n> \telif we are not at the top\n> \tprefix=$(git rev-parse --show-prefix)\n> \t\tcd_to_toplevel\n> \tfi\n> \n> and then inside bisect_next() you would check if $prefix exists, and go\n> there to run bisect--helper (or fail to go there and say \"cannot test\").\n> \n\nBut is the \"cannot test\" aka exit(127) the best we can do in this case?\nI think having a failing make, because someone has checked in code which doesn't\neven compile, is something totally different than having no Makefile at all,\nbecause the directory doesn't even exist. To me, this seems more like an error\nin the run script to not handle all the cases of the (dis)appearing directory.\n\nOn the other hand we don't waste much time trying to test such an \"untestable\"\ncommit, because this check will be fast because no compiling is involved.\nThe only time wasted will bethe build time for the \"usable\" commits and the\ntime the user needs to figure out why the heck some(/most?) of his commits\nare \"untestable\".\n"},{"id":"179947","messageId":"7vd3chage9.fsf@alter.siamese.dyndns.org","threadId":"29010","inReplyTo":"20111124070659.GC6291@m62s10.vlinux.de","subject":"Re: git-bisect working only from toplevel dir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-24T11:50:22Z","receivedAt":"2011-11-24T11:50:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann writes:\n\n> On Wed, Nov 23, 2011 at 12:45:18PM -0800, Junio C Hamano wrote:\n> ...\n>> Also didn't we make bisect workable in a bare repository recently? So the\n>> start-up sequence has to be something more elaborate like...\n>> ...\n>> and then inside bisect_next() you would check if $prefix exists, and go\n>> there to run bisect--helper (or fail to go there and say \"cannot test\").\n>\n> But is the \"cannot test\" aka exit(127) the best we can do in this case?\n\nYeah, thinking about it a bit more, it may probably be better to make it a\nfailure. The user explicitly asked \"be in _this_ directory and run make;\nit should succeed for the bisection test to pass\". If the bisection test\ncriterion the user was interested in was a successful build of the whole\nproject (not the subpart of the current directory), the user would have\ngone up to the top-level and \"bisect run make\" there.\n"},{"id":"180084","messageId":"20111129120612.GA30456@sigill.intra.peff.net","threadId":"29010","inReplyTo":"7vd3chage9.fsf@alter.siamese.dyndns.org","subject":"Re: git-bisect working only from toplevel dir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-29T12:06:12Z","receivedAt":"2011-11-29T12:06:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 24, 2011 at 03:50:22AM -0800, Junio C Hamano wrote:\n\n> > On Wed, Nov 23, 2011 at 12:45:18PM -0800, Junio C Hamano wrote:\n> > ...\n> >> Also didn't we make bisect workable in a bare repository recently? So the\n> >> start-up sequence has to be something more elaborate like...\n> >> ...\n> >> and then inside bisect_next() you would check if $prefix exists, and go\n> >> there to run bisect--helper (or fail to go there and say \"cannot test\").\n> >\n> > But is the \"cannot test\" aka exit(127) the best we can do in this case?\n> \n> Yeah, thinking about it a bit more, it may probably be better to make it a\n> failure. The user explicitly asked \"be in _this_ directory and run make;\n> it should succeed for the bisection test to pass\". If the bisection test\n> criterion the user was interested in was a successful build of the whole\n> project (not the subpart of the current directory), the user would have\n> gone up to the top-level and \"bisect run make\" there.\n\nThere are more possibilities than that. For example, imagine a project\nwith two sibling directories, one a library and one a command that is\nbuilt on the library. The library has a bug that we want to bisect, but\nthe command is the only mechanism we have to test the bug. The command's\nMakefile points to the library directory (e.g., using recursive\nmake[1]). It would be natural for the user to do something like:\n\n cd cmd\n make && ./test-cmd\n : hmph, it's broken\n git bisect start\n git bisect bad\n : I think v1.1 was OK\n git checkout v1.1\n make && ./test-cmd\n : Yep, let's run.\n git bisect good\n git bisect run 'make && ./test-cmd'\n\nIf, somewhere in the middle, the current directory doesn't exist, then\nour test harness does not exist. And we can't say good or bad, but only\n\"don't know\". Not knowing all of the details of what the user's command\ndoes, that seems to me to be the only safe option.\n\nThe worst case is that the bisection takes longer to run and says \"I\ndon't know where the bug is, but it's in this range\", and the user has\nto go back and run it again with a smarter test. But if we return \"no,\nthe test failed\" then we are likely going to just produce nonsensical\nresults, as our search is hitting on two different errors, and the \"bug\"\nwill appear to come and go.\n\nIt might be tempting to say that this case can't come up. After all, at\nthe branch tip the bug is there, and in v1.1 it isn't. What is the\nchance that the test harness goes away in the middle? In a linear\nhistory, not hight. But if you have history like this:\n\n\n D--*--*--*\n / \\\n *--*--A--B--C---*--E\n\nwhere:\n\n - A introduces the \"cmd\" directory\n - B is v1.1 (known good)\n - C is the location of the actual bug\n - D is on a side branch, but does _not_ have \"cmd\"\n - E is our current tip (known bad)\n\nthen we will have to search down the side branch towards D to look for\nthe bug.\n\nIf this seems contrived, well, it is. In 99% of cases, the directory\n_won't_ go away, and none of this will matter. And of course you can\nhave this exact same problem even without the directory issue. If your\ntest command is \"make && ./test-harness\", and the side branch doesn't\nhave the harness, then it's going to erroneously report the presence of\nthe bug. But that's your fault for writing a crappy test command that\nwasn't careful about verifying the pre-conditions.\n\nSo maybe it doesn't matter; there are a lot of ways to shoot yourself in\nthe foot with a bisection. I just think git should set a good example\nand default to being conservative with its claims.\n\n-Peff\n"}]}