Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > If we decide to go with yes/no, an option like: > > --yes-means=<it behaves like this> > > seems to me easier to understand. Though I recognize that it doesn't tell that > the behavior changed. What problem are you trying to solve? As I already said while discussing --has-property vs --used-to, I think that --yes-means shares the exact same downside as --has-property. The --used-to proposal was to make sure that people who are bisecting to find fixes would not by mistake say git bisect start --used-to='work fine' as it is very clear that bisecting in a history with something that used to work fine is _not_ hunting for a fix. When the users say git bisect start --yes-means='frotz is broken' is it clear to them that they are supposed to define what used to be the case (in which case "yes" is always mapped to "good")? If you are trying to allow them to say either old or new behaviour with --yes-means, how does your "bisect" know if it needs to map "yes" to "good" (regression hunting), or "yes" to "bad" (looking for a fix)? -- 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