"Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> writes: >> This reminds me; is there a way to suppress it because I'm about to >> give a large set of good and bit commits (perhaps because I'm > ^^^^^^^^^^^^^^^^^^^^ >> replaying part of a git biset log, minus one or two lines that are >> suspected of being bogus thanks to flaky reproduction), and so >> there's no point having git bisect figure the "next" commit to try >> until I'm done giving it a list of good/bad commits? > > i'm sure i'll regret asking this, but (assuming "bit" should read > "bad") is this suggesting one can hand bisect more than one bad > commit? i thought we just went through that discussion where there > could be only one bad commit but multiple good commits. clarification? The documentation you have been futzing with is about the fact that the initial set of known to be good/bad commits that "git bisect start <bad> <good>..." take can have one bad and zero or more good. What is being discussed in this thread is different (and I tried to clarify the fact by saying "what bad and good commits in what sequence"). Ted is talking about replaying the series of "git bisect (good|bad) $a_single_commit" that are recorded during a bisection session and can be read via "git bisect log". When Ted says "good commits" and/or "bad commits", he is not talking about giving all of them to a single invocation of "git bisect" command. The replay session will take one commit at a time (which is what "git bisect replay" does) and feed it to either "git bisect good" or "git bisect bad". Does it make sense? By the way, I do not think there is anything to regret in asking what you do not understand. Showing how much you know (and you don't) will allow others who communicate with you to calibrate their expectations, which eases later discussions; it is a good thing.
