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". If you start "git bisect start maint master" (and as always, "bad" comes before "good") because some operation is very slow in maint but somehow is usably fast in master, you are automatically hunting for a performance fix that you can cherry-pick to the maintenance track. 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. I really like that simplicity. -- 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