Re: [RFC/PATCH]: reverse bisect v 2.0

Jeff King [off-list ref] writes:

On Fri, Sep 30, 2011 at 11:13:25AM -0700, Junio C Hamano wrote:

quoted

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.

On Mon, Oct 03, 2011 at 10:00:25AM -0700, Junio C Hamano wrote:

quoted

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.

That makes sense to me. I think in either case, it would be nice to
mention the --used-to text when we take each step. We're already
outputting some status information there (like how many commits left).

quoted

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.

What you say makes sense, but isn't it just a problem of the name? IOW,
a much better name than "--has-property" would be "--started-to". That
would imply the exact same cutoff as --used-to, but negate only the
yes/no bit.

So you could say:

  # find a bug:
  git bisect start --used-to='work with --foo=bar'

  # or if you are looking for a specific undesirable behavior, you might
  # write:
  git bisect start --used-to='not segfault with --foo=bar'

  # but now you have a negation in your condition. So it might be more
  # natural to write it as:
  git bisect start --started-to='segfault with --foo=bar'

  # Or we can find a feature
  git bisect start --used-to='not respect core.foo'

  # but again, we have a negation. Instead:
  git bisect start --started-to='respect core.foo'

And the --started-to would literally be implemented as flipping the
meaning of "git bisect yes" and "git bisect no", and nothing more. IOW,
it's just another way of spelling "git bisect --reverse".

I know you wanted to emphasize the "older tree has this property" of
--used-to, but I think it is clear with --started-to that the older tree
obviously obviously had the negation of the property.

-Peff