On Wed, Nov 23, 2011 at 09:26:43PM +0100, Peter Baumann wrote: > > If we cd_to_toplevel, we can remember the prefix that we started from > > and cd to it before running the user's command, but there is no > > guarantee that it actually exists. Maybe that commit should be > > considered indeterminate then? > > > > Why not simply fail the run with exit(-1)? If the directory doesn't exist > in an older commit (which I think is not that common) git bisect should > simply stop and let the user proceed. The point of "git bisect run" is to run unattended until we reach an answer. I don't think most people would be happy with it not running to come to _some_ answer (e.g., imagine checking the results of an overnight "bisect run" in the morning only to find that it stopped 20 minutes in). That's why I think just marking the commit as indeterminate would be better; it jumps over parts of history that omit the directory, and will generally still come to a good conclusion. If it's possible to get an answer, that is. It might say "we can't come up with an answer because all of these commits are not testable". But that tells you something, too: your bisection test is not a good one. > And yes, I find the current behaviour to forbid running git bisect from > a subdirectory slighly annoying and I'm glad somebody took a stab at it. Agreed. I often bisect by hand with two terminals, doing something like: [terminal 1] git bisect start ... make [terminal 2] cd t ./t1234-whatever -v [terminal 1] git bisect good|bad make [terminal 2] ./t1234-whatever And then want to type "git bisect good|bad" into terminal 2. Which doesn't work, of course (yes, in this simple case I could automate the running of the test script from terminal 1; but often times it is simpler to just eyeball the output during the bisection). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html