Jeff King <peff@xxxxxxxx> writes: > On Fri, Sep 30, 2011 at 11:13:25AM -0700, Junio C Hamano wrote: > >> I wonder if something along the following line would make the usage more >> pleasant and self-explanatory: >> >> $ git bisect start --used-to='git frotz says xyzzy' v0.99 master >> Bisecting: 171 revisions left to test after this (roughly 8 steps) >> $ ... build and then test ... >> $ git bisect tested >> You are trying to check: git frotz says xyzzy >> Does the result satisify what you are trying to find [y/n]? yes > > I like this idea a lot. My "yes/no" thing was a "if I were designing > bisect from scratch today..." suggestion, but having something like > --used-to makes it a natural addition to the regular good/bad interface. > And I really like the prompt to help people remember what it is they're > declaring each time. I forgot to clarify that "tested" was only to help users who wanted reminder; if the user is confident with the usual "yes/no", the interactivity is not required. > However, --used-to feels a bit backwards to me. I think of it as > "--has-property" or something similar. I do not think --used-to='frotz says xyzzy' is a good phrasing at all; it is grammatically incorrect. But --has-property has one large downside. At least --used-to makes it clear that the user is supposed to decribe the property of the tree in the past. Let's step back a bit to understand why I think this is not optimal. The low-level "bisect" machinery is about bisecting a history whose ancient commits have a property (e.g. "used to work" or "used to be broken") and more recent ones does not have the property to find one commit where the property is lost. Conceptually, this "property" does not have any value judgement associated with it, but historically, we called that property "good" (and lack of it "bad"), which caused confusion at the surface level when looking for a recent fix. The user has to say "ah, this is still broken and does not contain the fix---good" with a twisted mind. To dissociate the value judgement from the "property", it is a good idea to allow users to operate the bisect machinery without using "good/bad", and "yes/no" is a good pair of words to use. However, the user still needs to be aware of the fact that the "property" must exist in older history and must be lacking in newer history. "--has-property" strips the value judgement but does not surface this crucial point to the UI. When the user wants to find a recent fix, the property can be spelled in various ways: "it is broken", "it no longer is broken", "it is fixed", "it works", etc.. We need to map the 'yes' answer to 'bad' if --has-property=works is given and the user is looking for a fix, not a regression. But --has-property does not explicitly tell the user that the property must exist in the past and absent in the present. My --used-to was an attempt to surface this "we are looking for a commit that changed the condition that used to hold, but no longer holds for recent commits" to the UI level and force "yes == observation consistent with the older tree" and "no == new tree" interpretation, without a need to map yes/no to good/bad or bad/good depending on what is hunted. The alternative approach of "bisect start --reverse" was an attempt to allow swapping this mapping. When reverse is in effect, "good" maps to "observation consistent with the newer tree". I do not _mind_ mapping if it turns out to be absolutely necessary, but I wanted to see if we can do this without one. > something appeared (be it a bug, a feature, or whatever). But I guess it > depends on what you are bisecting. In my case, "yes" would be the > current "bad", and "no" would be the current "good". I think we are aiming for the same thing, but I think you are assuming that a naive user would always describe the condition that used to hold with --has-property without being told; I do not think that assumption holds. -- 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