On 06/28/2015 09:32 AM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > >> I understand that the user might make a mistake when marking the initial >> commits, but as soon as bisect says >> >> Commit <sha1-abbrev> is an ancestor of <sha1-abbrev>, so I >> will look for the commit that caused the transition from >> "xyzzy" to "plugh". >> >> then I hope the user will notice and correct her/his mistake. >> >> For example, a session could be started with >> >> git bisect start --mark=broken <committish> --mark=fixed <committish> > > Interesting. > > If we extend that line of thought further, maybe we do not even need > to add new/old, fixed/broken, or slow/fast. > > You just _always_ say "good" or "bad". If something is slow, you > say "bad" and if something is fast, you say "good". Yes, I think "good" and "bad" would usually be perfectly intuitive and would almost always be usable. > [...] > No need for "bisect new", "bisect old", or "bisect terms", let alone > "bisect terms --new=fast --old=slow". The tool just does the right > thing because it already has the information necessary to infer what > the user means by 'good' and 'bad', and the initial topology determines > which transition, either from 'good' to 'bad' or from 'bad' to 'good', > the user is hunting for. Correct. The only caveat is if the initial "good" and "bad" commits are not ancestrally related to each other. But in this case, I think "bisect" asks the user to test a merge base anyway, and once that one has been tested it will be clear which of the labels comes "before" the other. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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