Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 06/28/2015 09:32 AM, Junio C Hamano wrote: >> >> 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. The more I look at the proposal, the more I like it. The old way of thinking is that we need to keep 'bad' for newer one and 'good' for older one, that required us to invent 'broken' vs 'fixed', or value neutral 'old' vs 'new'. Then we extend it to a random pair of 'terms', but we reserve 'good', 'bad', etc. and do not allow the user to say "old was bad, new is now good". With your proposal, the user can just say "oh this is good", vs "oh this is bad". The mental model becomes much simpler. I _think_ bulk of Antoine and Matthieu's work can be salvaged/reused to implement the proposal, but now it would be more clear that $name_good and $name_bad is a bad way to name internal variables and files in $GIT_DIR. The inferred 'ah you are hunting for regression' mode would call old ones 'bad' and new ones 'good', they have to be given value neutral names, e.g. $name_old and $name_new. -- 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